From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: base Date: Thu, 26 Aug 2010 17:28:57 +0200 Organization: Organization?!? Message-ID: <87wrrd4cli.fsf@lola.goethe.zz> References: <20100822120642.GA1794@muc.de> <87hbij6hib.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4nf7ezq.fsf@catnip.gol.com> <878w3v7dd2.fsf@catnip.gol.com> <83wrrfmljv.fsf@gnu.org> <87d3t75crc.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwy2g7i2.fsf@telefonica.net> <83r5hmmrz0.fsf@gnu.org> <877hjefll8.fsf@telefonica.net> <83mxsam5lh.fsf@gnu.org> <87eidm5a0n.fsf@catnip.gol.com> <87pqx5ec72.fsf@telefonica.net> <87lj7te8qp.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1282836570 4259 80.91.229.12 (26 Aug 2010 15:29:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Aug 2010 15:29:30 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 26 17:29:29 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OoeOM-0004ep-Ix for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 17:29:26 +0200 Original-Received: from localhost ([127.0.0.1]:53208 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoeOL-0003oE-OK for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 11:29:25 -0400 Original-Received: from [140.186.70.92] (port=54780 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoeOA-0003m8-Qv for emacs-devel@gnu.org; Thu, 26 Aug 2010 11:29:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OoeO8-0001LV-M9 for emacs-devel@gnu.org; Thu, 26 Aug 2010 11:29:14 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52543) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OoeO7-0001Ky-R7 for emacs-devel@gnu.org; Thu, 26 Aug 2010 11:29:12 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OoeO4-0004RR-GZ for emacs-devel@gnu.org; Thu, 26 Aug 2010 17:29:08 +0200 Original-Received: from p508ed3fa.dip.t-dialin.net ([80.142.211.250]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Aug 2010 17:29:08 +0200 Original-Received: from dak by p508ed3fa.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Aug 2010 17:29:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 32 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508ed3fa.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:OvWhDXqJgdv+y2yuda0CKP+PPMs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129258 Archived-At: Óscar Fuentes writes: > Eli Zaretskii writes: > >> So you are saying that there's no way a user can understand how to use >> git efficiently without knowing about SHA1, hashes, blobs, index >> files, and how they all live happily in disk files and point to one >> another? > > It is perfectly possible to use git without knowing its model, in the > sense that you can store your changes on the repo, see logs, etc. More > or less like CVS or Subversion (or Bazaar!) where the user knows recipes > for dealing with a restricted, mostly simplistic, set of > requirements. On the long term (or not so long) it is not the most > cost-effective approach. > > For any dVCS, revision IDs are a core concept. A user that doesn't > understand revision IDs eventually will suffer the consequences of his > ignorance. That applies to git's SHA1 hashes and to whatever bzr uses as > IDs. Blobs and trees are on the foundations of git and defines how it > stores information. Having some knowledge about them makes easy to > understand why git does not track empty directories, Actually, it doesn't make it easy to understand. After all, git tracks symbolic links which have as little information beside the entry itself as directory entries do. It would be easy for git to make an additional entry for the directory entry itself. -- David Kastrup