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 02:58:59PM -0500, Eric S. Raymond wrote:
 > 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.)

Mercurial, or CVS, or Subversion, or everything else...

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

Yes, it is. The input (the CVS repository) contains what this
discussion has been called branch coloring data; the output (the
fast-import stream) does not contain this data. Therefore it's been
thrown away.

Whether you can or can't reconstruct it correctly again later is
orthogonal to whether it's been thrown away.

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

Once you have manufactured some merge commits, when reconstructing and
you cross a merge commit going backwards, how do you know which of the
ancestors is the same branch and which is another? And how do you know
which other branch it is? I don't see that the git-fast-import format
can preserve this information, any more than it preserves per-commit
branch metadata.

 > I know you don't understand this,

Speak for yourself. Anyway, there's clearly no point discussing this
any further.

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