From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sergey Organov Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Wed, 19 Nov 2014 18:15:51 +0300 Message-ID: References: <20141114230235.GF3168@acm.acm> <20141117141123.GA4294@acm.acm> <83lhn89zxn.fsf@gnu.org> <83bno49xtw.fsf@gnu.org> <20141118224326.GA5167@acm.acm> <87mw7n8k0f.fsf@Rainer.invalid> <20141119135530.GA3986@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1416410209 23457 80.91.229.3 (19 Nov 2014 15:16:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 15:16:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 16:16:42 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xr6zk-0004ol-1r for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 16:16:36 +0100 Original-Received: from localhost ([::1]:58965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr6zj-000683-Jp for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 10:16:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44617) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr6zP-00066C-Jj for emacs-devel@gnu.org; Wed, 19 Nov 2014 10:16:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr6zJ-00085A-RO for emacs-devel@gnu.org; Wed, 19 Nov 2014 10:16:15 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:49132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr6zJ-00084z-Kw for emacs-devel@gnu.org; Wed, 19 Nov 2014 10:16:09 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xr6zF-0004ZH-La for emacs-devel@gnu.org; Wed, 19 Nov 2014 16:16:05 +0100 Original-Received: from 89.175.180.246 ([89.175.180.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 16:16:05 +0100 Original-Received: from sorganov by 89.175.180.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 16:16:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 103 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89.175.180.246 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177758 Archived-At: Alan Mackenzie writes: > Hello, Achim. > > On Wed, Nov 19, 2014 at 01:14:40PM +0100, Achim Gratz wrote: >> Alan Mackenzie writes: >> >> Well, given the following history (time goes from left to right): > >> >> - C - D <- foo >> >> / >> >> ... - A - B >> >> \ >> >> - E - F <- bar > > >> >> what branch commit A was made on, 'foo' or 'bar'? > >> > Quite clearly, A was committed on branch foo, since bar didn't exist at >> > that time. > >> Neither foo nor bar might even have existed at the time commit A was >> made (or even any of the other commits shown). > > OK, commit A might have been made on some other branch not in the > diagram. But commit A was made before commit B (that is what these lines > _mean_) and commit B was made before branch bar was created (and possibly > before branch foo if that was branched of of B also, rather than being > the continuation of the branch A was made on). > >> > Are you saying that at B, when bar is branched from foo, git discards >> > all information about this branching, remembering only that there are two >> > branches which are henceforth of fully equal status where before there >> > was just one? > >> Again, the branch diagram tells you nothing about the sequence of >> events. > > It must do. D is based on C is based on B, and F is based on E is based > ob B, which in its turn is based on A. Commit D thus happened after C, > etc. We have a partial ordering, not a total ordering though. Yes, and this still does not tell you "on which branch" commit A was created. Here is very simple example how this history could have been created: A <- bar A - B <- bar <- foo A - B <- bar - C - D <- foo / A - B <- bar - C - D <- foo / A - B - E - F <- bar Now, after I gave you the sequence of events, what new /essential/ information have you got? How it makes any difference if commit A was not made in the manner you originally thought ("on branch 'foo'")? [...] > >> …or your expectation of what branches are is broken. > > The very essence of a branch is its creation on the trunk (or other > branch) and divergence from it. Its point of creation is essential - > without it, it isn't a branch at all. It seems git simply discards > this information. Wow! We've finally learned something! Do you have an idea of why it discards it? My bet is that it's because it's not worth the trouble to maintain it, especially universally, in distributed manner. Another essential question is: can you implement your favorite abstraction on top of what Git provides? Yes, you can. As a very simple method, name your branch 'foo' starting from branch 'bar', say, 'bar/foo'. Then you will probably be able to ask Git where 'bar/foo' has diverged from 'bar', should you ever need it (that I doubt). Side note: 'trunk', or 'master' is not any different for Git then any other branch. Just in case... >> Branch foo consists of a label pointing at commit D and everything >> reachable from D is on that branch. > > That is where git's abstraction is broken. A is reachable from branch > bar, yet isn't on it and never has been - it's on the trunk, (or maybe > branch foo). That's the whole point. Git is somehow successful while it (deliberately) has no notion of your lovely abstraction. How comes it still provides enough functionality people need, without such a fundamental thing? Can't it be that it uses more suitable abstraction that doesn't have all the troubles your favorite abstraction has when one tries to implement it in distributed manner? -- Sergey.