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

[Achim Gratz]

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