From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Wed, 19 Nov 2014 13:55:30 +0000 Message-ID: <20141119135530.GA3986@acm.acm> 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> 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 1416405390 4309 80.91.229.3 (19 Nov 2014 13:56:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 13:56:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 14:56:23 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 1Xr5k6-0005aJ-UA for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 14:56:23 +0100 Original-Received: from localhost ([::1]:58309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5k6-0006rA-Ln for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 08:56:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5jw-0006qz-FK for emacs-devel@gnu.org; Wed, 19 Nov 2014 08:56:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr5jo-0003eY-SC for emacs-devel@gnu.org; Wed, 19 Nov 2014 08:56:12 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:30094 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5jo-0003cX-Hm for emacs-devel@gnu.org; Wed, 19 Nov 2014 08:56:04 -0500 Original-Received: (qmail 136 invoked by uid 3782); 19 Nov 2014 13:56:03 -0000 Original-Received: from acm.muc.de (pD951A47A.dip0.t-ipconnect.de [217.81.164.122]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 19 Nov 2014 14:56:01 +0100 Original-Received: (qmail 4154 invoked by uid 1000); 19 Nov 2014 13:55:30 -0000 Content-Disposition: inline In-Reply-To: <87mw7n8k0f.fsf@Rainer.invalid> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 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:177749 Archived-At: 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. > Your assumption about when something branched off what seems to be > based on the sequence of labels A..F. There are no such orderable > sequences. E might have been created before F or after, .... How can E have been created after F? That doesn't seem to make sense. > but that is a moot point now that the commits have been entered into > the DAG in the order E,F. ??? A "commit" is the action of appending something onto a tip of the DAG. Commits do not somehow exist independently of a DAG and then get entered into it. > > If this is indeed the case, it is not surprising that git's > > abstraction of branching is so broken. > …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. > 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). The practical outcome is that git doesn't keep track of your branches. You've got to remember your branching structure (or write it on a piece of paper) if you ever want, say, to get a list of changes made on branch bar. This is something I would expect a VCS to do for me automatically. I think that is what the "..." in "master...bar" is all about. > You can check the _local_ history of such labels in the reflog, but > they aren't kept around forever. Git gives you a guarantee that once > you have D the DAG will always stay exactly the same no matter what. > It doesn't care what branch label or how many are pointing to D as long > as D does not become dangling. Yes, that's what I'm saying, I think. > Regards, > Achim. -- Alan Mackenzie (Nuremberg, Germany).