Re: Split commit naming

["Eric S. Raymond" <esr at thyrsus dot com>]

Joseph Myers <joseph@codesourcery.com>:
> My question is: is it a stable interface to reposurgeon that the portions 
> of such a split commit will always be numbered in lexicographical order by 
> branch name (or some other such well-defined stable ordering), so I can 
> write <80870.2> in gcc.lift and know that some reposurgeon change won't 
> accidentally make that refer to the portion of the commit on 
> gcc-3_3-branch instead?

Your timing is fortuitous, as I just finished rewriting the code for 
mixed-commit handling and it is fresh in my mind.

The old behavior was indeed that cliques were lexicographically ordered
by branch.  This was not documented.  The master branch still uses the
old code.

Current behavior on my development branch is that fileops are not
sorted before splitting; you get whatever order they had in the dump.
I will change this so they are sorted by pathname and document that.

And...it's done.

You won't see the new code for a few days, until I finish the analyzer
rewrite.  The old code had become overgrown and brittle; I spent a
week trying to find a strategy to get around a particular
pathological-tag defect only to discover that I could no longer
modify the analyzer without cascade bugs.

I'll describe the problem, since I think the GCC repository has some
of these and they may explain some of your earlier bug reports.

Suppose you create a tag, then later on modify the tag copy by
copying to one of its subdirectories.  When translating to git
you want to attach the tag reference to the revision the *second*
copy came from.  Simple in concept but the obvious implementation
of root-finding prefers the earliest copy.

When it proved impossible to change this wthout producing a cascade of
breakage, I faced up to the necessity of a scrap-and-rebuild.  It's
not done yet, but it's pretty well advanced.
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>