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

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

On Tue, Jan 13, 2015 at 12:51:26AM -0500, Eric S. Raymond wrote:
 > >    (4) Do your tools avoid this problem?
 > 
 > Answering the last question first:
 > 
 > No, they don't.  They can't, because git and its fast input streams
 > don't store the right kind of metadata.

Ok then. What if anything can be done about this?

 > However, I note that CVS doesn't handle branches this way either.  In
 > CVS, as in git "a branch is a self-moving tag that names the head of the
 > branch, that is, a branch is a version.".  There is nothing else there.
 > The same is in effect true of SVN, though the details are odd and
 > slightly different.

This is absolutely not true. In CVS, when you create a branch, it gets
a version number that refers to the whole branch (a version with an
odd number of components) and all commits on the branch are numbered
using that as a prefix.

For example, looking arbitrarily in src/Makefile because it's easily
reached, I find that the prefix for the netbsd-5 branch is 1.262.2,
and there are five commits on it, 1.262.2.1 through 1.262.2.5. Also it
seems that netbsd-5-1 branched off from 1.262.2.3.

The numbers tell you this, and they don't change once committed. What
commits happened on which branch is part of the permanent metadata,
and you don't have to search the history relationships.

I have no idea why you might think this is not the case.

 > There are only two options here: the VCS can either implement
 > branches as stored and persistent node colors a la Mercurial, or
 > accept that line-of-development information will be lost at merges
 > a la git.

I can think of at least one other alternative, but that's not
important at the moment. What *is* important is that the repository
conversion can be done without throwing this data away if the target
is not git. (And, ideally, even if the target *is* git, it would be
better to keep the information as some kind of auxiliary or external
metadata in caes further conversions are done later.)

 > I am not a partisan in that dispute.  99% of the conversion process, up to
 > the point where we feed finished fast-import streams to an importer, will
 > be the same either way.

So how is full branch metadata supposed to be recorded in the
fast-import stream? You said above that it wasn't supported.

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