From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: base Date: Thu, 26 Aug 2010 16:42:06 +0200 Message-ID: <87lj7te8qp.fsf@telefonica.net> References: <20100822120642.GA1794@muc.de> <87r5ho5gyr.fsf@uwakimon.sk.tsukuba.ac.jp> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282833761 23613 80.91.229.12 (26 Aug 2010 14:42:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Aug 2010 14:42:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 26 16:42:35 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 1Oodf1-000150-I8 for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 16:42:35 +0200 Original-Received: from localhost ([127.0.0.1]:44261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oodf0-0008Bk-Ug for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 10:42:34 -0400 Original-Received: from [140.186.70.92] (port=49038 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oodeq-00089H-9l for emacs-devel@gnu.org; Thu, 26 Aug 2010 10:42:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oodel-0008N9-Pc for emacs-devel@gnu.org; Thu, 26 Aug 2010 10:42:24 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:55133) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oodel-0008Md-Bm for emacs-devel@gnu.org; Thu, 26 Aug 2010 10:42:19 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Oodei-0000tE-SI for emacs-devel@gnu.org; Thu, 26 Aug 2010 16:42:16 +0200 Original-Received: from 83.38.73.98 ([83.38.73.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Aug 2010 16:42:16 +0200 Original-Received: from ofv by 83.38.73.98 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Aug 2010 16:42:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.38.73.98 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:eZE/8JNNAvZeveQShuZ3FNIhTMk= 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:129255 Archived-At: 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, how file renaming is (un)supported, why some operations are blazingly fast but others (`annotate') are not, etc. The index is one of the most useful innovations of git. If you insist on ignoring its existence you are missing a really good feature. Almost every operation in git is about creating trees, blobs and updating pointers (refs). Do you want to see a file on another branch without switching to it? If you know about refs, trees and blobs, it is straightforward. Want to temporaly reset your working copy to some point on the past? If you know what a git ref is then you already know that it is possible. Refs are arranged on the file system on the same way you can name them (i.e. "git log refs/remotes/origin/master" will work fine) You will agree that having an insight on how a tool is designed increases your effectiveness while using it. Some tools makes easy to gain that insight, because its design is simple enough, or because its documentation is very good. Such a tool has an advantage over its competitors. [snip]