[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: git branches (was: Re: Reply to David Holland's notes and comments)
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
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
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>
Main Index |
Thread Index |