[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)
David Holland <dholland-tech%netbsd.org@localhost>:
> I assure you there is no confusion, only lack of clarity. Allow me to
> 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
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
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Main Index |
Thread Index |