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

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > > >>              - C - D <- foo
 > > >>            / 
 > > >> ... - A - B
 > > >>            \
 > > >>              - E - F <- bar

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

Yes.

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

You can't tell that from the diagram though.  While the DAG gives you
information about the (partial) order of commits, it tells you nothing
about what branches existed at any given point of time except NOW, or
where the commits were actually created.  For example, starting on
trunk, you can

    bzr commit -m A       # all commits are preceded by hacking
    cd ..
    bzr branch trunk foo
    bzr branch foo bar
    cd trunk
    bzr commit -m B       # trunk and foo have diverged
    cd ../bar
    bzr pull ../trunk     # bar and foo have diverged
                          # at this point we must have 3 branches
                          # since bar did not branch from trunk
    bzr commit -m E
    bzr commit -m F
    cd ../foo
    bzr pull ../trunk     # trunk and foo have reconverged
    bzr commit -m C       # trunk and foo have diverged
    bzr commit -m D

I have no idea how you propose to interpret that consistently with
your claims about knowing where and when a branch was created, or what
commits are on which branch, apart from reachability.

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

Uh, if it's not a branch, what in the world is it?

 > It seems git simply discards this information.

Yes.  AFAICS it's not terribly useful.  I used to use a tag in CVS,
and that could be done in git, too:

    # echo 'git tag $1-bp-`date +%Y%m%d%H%M%S` > /usr/local/bin/git-makenode
    # echo 'git branch $1 $2' >> /usr/local/bin/git-makenode
    # chmod 0755 /usr/local/bin/git-makenode

but I find git's ".." notation gives me everything I want.

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

Actually, I think *your* abstraction is incompatible with all DVCSes.
All support a mode of operation where repo == branch == workspace.
Now, suppose I have a branch foo, and from its parent directory I do
"$VCS clone foo bar".  Nobody (with the possible exception of you)
would say that bar is an empty branch, and that directory bar contains
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.

Most of the time this is trivial.  "git log master..bar".  But I don't
understand why you care *where* the changes were made.  I always am
looking for a set of commits that represent the changes by which two
revisions or branches differ; I don't care that C is a branch of B
which branched from A, I just care about A and C (and want to know
what happened on B as well as C since "our" branches forked from A).

 > I think that is what the "..." in "master...bar" is all about.

You want ".." here.  "..." gives the changes on *both* branches since
the fork.  Note that a VCS that knows about branches is no help if you
want "bar..master" or "bar...master": master goes all the way back to
root!  Whose abstraction is broken here?