[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)
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
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
> I know you don't understand this,
Speak for yourself. Anyway, there's clearly no point discussing this
David A. Holland
Main Index |
Thread Index |