Re: Obscure error/warning/information message from git pull

[Alan Mackenzie]

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).