From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Wed, 19 Nov 2014 16:24:25 +0100 Organization: Linux Private Site Message-ID: <87ioib8b86.fsf@Rainer.invalid> 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 1416410702 32085 80.91.229.3 (19 Nov 2014 15:25:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 15:25:02 +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:24:56 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 1Xr77n-0007zD-Bg for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 16:24:55 +0100 Original-Received: from localhost ([::1]:59002 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr77m-0004AX-Vt for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 10:24:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr77d-00045W-2m for emacs-devel@gnu.org; Wed, 19 Nov 2014 10:24:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr77W-0001b8-Oh for emacs-devel@gnu.org; Wed, 19 Nov 2014 10:24:45 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:49762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr77W-0001b1-Dr for emacs-devel@gnu.org; Wed, 19 Nov 2014 10:24:38 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xr77V-0007u6-G8 for emacs-devel@gnu.org; Wed, 19 Nov 2014 16:24:37 +0100 Original-Received: from pd9eb05af.dip0.t-ipconnect.de ([217.235.5.175]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 16:24:37 +0100 Original-Received: from Stromeko by pd9eb05af.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 16:24:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 114 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb05af.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.51 (gnu/linux) Cancel-Lock: sha1:vYAkxnMlekniz3aVZrOLdprFcDE= 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:177759 Archived-At: Alan Mackenzie writes: > 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). No, that's only what the published or local history looks like. >> > 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. When that graph was constructed the objects must have been available in that order. That doesn't mean they would have had to be created that way. >> 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. This is a distributed VCS. Somebody may have pushed E, then someone else rebased his older F on top of that. You are looking at it in a repo where that brach is called bar, but it may have come from a repo where it was called something else. Again, your only guarantee is this: if you look at some other repo at any point in time and have the SHA1 for the objects pointed to by foo and bar, provided they exist, then you'll end up with the exact same DAG as what you have from foo and bar in your repo right now. >> 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. No, but there are multiple DAG, at least one in each of the existing repos. In Git a commit is made immutable precisely by recording the parent(s) and changing the parent -- moving the commit in the DAG -- changes it's SHA1, but unless there are conflicting edits the action of the commit can be applied in many positions in each of the possible versions of the DAG. >> > 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. No it's not. Let's assume that foo and bar are remote branches from different repositories. In these repositories, there are no branches and A is clearly reachable from the branch tips (probably called master) in both repositories. But when I look at them in a single repository, they have been diverging after B. So nobody has done this "very essential" thing you talk about, yet clearly we have a branch point. >> 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 your problem all along and it simply doesn't make any practical sense in a dVCS. What if I later throw away foo and keep only bar? Should that make A disappear? If A has created file a.el and none of the commits ever changed it, is it not available in branch bar? Why should I care that some developer thought foo was the trunk when everyone else clearly has decided that for now it's bar? Even nature disagrees with your view… If you cut the main branch from a tree, one of the other branches will take its role. Depending on when you do this it will be close to impossible to tell from the old tree that the trunk has been a branch. So, nature and Git know a branch when they see one, not when you first label it. It's an emergent feature and not a designated one. > 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. Absolutely not. The purpose of three dots "..." is (and again, read the documentation for gitrevisions) to show all commits that are reachable from either master or bar, but not both. So it finds the branch point and shows all commits on either side of that. In other words, if you were to merge the two branches, then all the commits shown in the log yould be reachable from the merged branch (and be part of either branch). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada