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

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Jan 14, 2015 at 08:19:10AM -0500, Eric S. Raymond wrote:
 > >  > 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.

Those aren't "sticky tags", that's a different CVS phenomenon. Those
are "branch tags".

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

I assure you there is no confusion, only lack of clarity. Allow me to
summarize:

1. git-fast-import streams cannot represent complete branch metadata.
(This is because git doesn't support complete branch metadata.)
2. Because CVS doesn't support merge commits, it's possible to
reconstruct the branch metadata after throwing it away when producing
the git-fast-import stream.
3. However, this precludes any attempt to reconstruct merge commits
from the CVS data.

The original question I asked is answered by point 1. The answer to
the other question I asked (whether there's any way to preserve the
branch metadata instead of trying to reconstruct it) seems by your own
statements to be "no". Except by using other less limited tools.

 > Are you trying to achieve understanding or picking a fight?  

I don't understand why you persist in asserting that CVS branches are
equivalent to git branches when they obviously aren't. Or that no
information is being thrown away in the conversion.

(Also, please don't fall into the standard git advocate's trap of
assuming anyone who questions the holy git doesn't understand version
control, or distributed version control, or any other similar flavor
of the day.)

-- 
David A. Holland
dholland%netbsd.org@localhost