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

1 is correct, given a Mercurial-like assumption about what constitues
"complete".  A git partisan would say that Mercurial "branch" metadata
is misnamed, and a Bitkeeper fan would probably add "Oh, yeah, that's
an L.O.D." (I think.  I've never used Bitkeeper. I could have that wrong.)

2 is incorrect. Branch-ordering data is not "thrown away" in fast-import 
streams, it's sufficiently expressed by the distinction between "parent"
and "merge" ops. Without that distinction, correctly re-coloring the Git
DAG would be impossible. With it, you can perfectly recover CVS-like
commit IDs. 

3 is incorrect.  You can both recover the branch coloring and reconstruct
merge commits.  The only thing you cannot do is, *after* translation, add
a merge commit and branch-color it without making an assumption about
which ancestor represents the "real" line of development that may be wrong.

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

There's no limit. No information is actually lost.  

I know you don't understand this, and any further explanation would
just be repeating myself.  If you persuade core to go with Mercurial,
I'll prove this point in action.

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

I'm not a git advocate, so that should be easy.  I will be happy to help you
set up a Mercurial conversion process if you can persuade core to make
that choice.  I neither need nor want to be involved in any Git vs. mercurial
fight.
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>