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

[David Kastrup <dak@gnu.org>]

Alan Mackenzie <acm@muc.de> 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).

Shrug.  That's pure conjecture.  The graph can end up in that manner in
a variety of different ways.  It's like trying to proclaim that some
data structure like a linked list must have been created in a particular
order.  That's just not an invariant of the data structure, and it is
not seminal to it, anyway.

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

The partial ordering is one of commit dates but does not have any
relation to branches.

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

So Git does not have branches.  Happy?

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

Git does not maintain abstractions for the only sake of complicating
matters.  Any tangible data needs to be maintained, merged, transferred,
and needs semantics for all of the possible operations on and with
commits.

> The practical outcome is that git doesn't keep track of your branches.

Correct.  Whatever information it hands out about branches, it deduces
from the commit tree.

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

Nonsense.  You first define what you even mean by "on branch bar".  If
you mean "after branching off of master", you get the list by saying

git log master..bar

If you mean something else, there are other things you may say.

> 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 are aware that ... is not the same as ..?

-- 
David Kastrup