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

[Sergey Organov]

Alan Mackenzie <address@hidden> 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.