Re: git branches (was: Re: Reply to David Holland's notes and comments)

["Eric S. Raymond" <esr%thyrsus.com@localhost>]

David Holland <dholland-tech%netbsd.org@localhost>:
>  > Aha.  I see.  You're identifying "the branch" with its CVS prefix;
>  > I'm identifying it with its name, the sticky tag on the end.
>  > Terminology problem.
> 
> No, it's not a terminology problem. First, the tag isn't on the end:
> 
>    % cvs log Makefile | grep netbsd-5:
>            netbsd-5: 1.262.0.2
> 
> This number (which does not change over time) tells me that netbsd-5
> was branched from version 1.262 of this file, and that the commits on
> the branch are numbered (in order) 1.262.2.*; it does not label the
> branch head or tell me where the branch head is. For that I have to
> look for the highest-numbered 1.262.2.* commit.

I know how sticky tags work.  I think of them as being at the end
because if you use them in a revision spec they resolve to the tip
version of the branch, not the root that they're obviously related to
by number.  They move with the tip.
 
> Second, it's a semantic difference:
> 
>  > The trouble with noticing that branch prefixes correspond to a unique 
>  > coloring scheme is that it doesn't help us in any way.  We already know
>  > we can induce a unique branch coloring (in fact, the same one) just from
>  > knowing which the oldest branch at any junction is.
> 
> We don't need to induce a branch coloring; we already have the branch
> coloring, it just requires recording the mapping 1.262.2.* <->
> netbsd-5. All the 1.262.2.* versions should be recorded on the
> netbsd-5 branch, and hey presto, we have the branch metadata we need
> for a correct conversion to Mercurial. Or Subversion, or Monotone, or
> anything else other than git.

That's right. Your method of branch coloring by prefix is provably
equivalent to the naive coloring algorithm starting from the branch
tips that I described. You seem to think they have different
consequences somehow.  They don't.

We've been over this ground before.  I began by explaining that *even
in git*, it's trivial to do branch coloring on a treelike DAG.  There
is no loss of information moving from CVS to git and no problem *until
you do a true (non-cherrypick) merge*.

I suspect the reason you remain confused about this is that you're
used to VCSes in which all merges are cherrypicks, and thus you expect
well-definedness of the branch coloring to be preserved by commits
after the translation. The core of the problem is that in git this is
*not true*.

That problem has nothing to do with any deficiencies in the
input-stream format or my tools.  It's much more fundamental than
that. In truth, you're being mugged by graph theory.

>  > > So how is full branch metadata supposed to be recorded in the
>  > > fast-import stream? You said above that it wasn't supported.
>  > 
>  > It isn't.
> 
> Ok, so it doesn't work then. So, why is the git-fast-import format so
> wonderful?

Are you trying to achieve understanding or picking a fight?  

Since you consider Mercurial-style branch coloring so important, I think you
should find or create a group that is writing a Mercurial-based plan.
I'll cheerfully help that group too.  If required, I'll hack an importer
so that it turns import-stream branches into Mercurial branch coloring
by propagating color from the branch tips.

Mercurial, because it stores a node's branch ID as part of its metadata 
and assigns branch IDs based on parentage at commit-creation time, will
give you what you think of as "true" branches; git will not.

Once again, this difference has nothing to do with any problems in
fast-import streams or my tools, and you can't fix git's bookmark-like
branch semantics by arguing with me about them.
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>