[Nut-upsdev] git conversion progress

[Eric S. Raymond]

Charles Lepple <clepple at gmail.com>:
> A complete defect report would be great, but bear in mind that the
> reposurgeon code has changed drastically in terms of what it is
> trying to do automatically, and as such, I am hesitant to finish
> traversing the other several hundred commits until I have an idea of
> what you are planning to do next.

Fair enough.  I suppose from the outside it's difficult to tell that the
objectives are not changing as fast as the implementation.  

I have reproduced the apparmor branch problem and am pursuing it.

> I think that given the NUT project's acceptance of SVN's
> shortcomings, we tended to merge infrequently. This is probably why
> the git-svn conversion is our "90% solution" - git-svn does not
> attempt to reproduce SVN merges, and since it is not trying to alter
> the topology of the repository, there seems to be a lower risk of
> lost data.

This sort of concern is why one of reposurgeon's design rules is
"never throw away data unless the user tells you to".  In particular it
is why when I junk a copy or tip-delete commit it turns into a tag instead
of vanishing - you have to *tell* reposurgeon to dispose of it with a "delete
obliterate"

> In terms of where I would want to spend the most time for a
> high-quality repository conversion (for NUT in particular), it would
> be to enable easy manual merges, with the option to tell
> reposurgeon, "I know what I'm doing - ignore the sanity check".

merge = attempt this merge and report if it's clean, 
merge perform = do this merge, 
merge perform force = do this merge ignoring sanity checks

It's already designed exactly the way you want it.

> Automatic merge detection is an unexpected bonus, provided that it
> preserves the integrity of the repository. To be honest, I'd rather
> have reposurgeon present a list of automatically-detected merge
> points that I could choose from (especially during an incremental
> refinement process like this).

There is no danger to the repo integrity from *detection*; only when we
actually edit merge points.  That's why "merge perform" is separate
from "merge", so that you can know the former won't perform any
write operations.

>Maybe it can do this already - I haven't looked at the code that
>closely, because the little time I have had to spend on this has been
>focused on inspecting the output.

Automatically detecting *all* potential merge points is expensive - worst
case is O(n**2) in the number of commits.  The workflow is designed around the
assumnption that a human will identify potential merge points, test them
with "merge", and if they're clean di a "merge perform".

> Does reposurgeon take commit IDs as parameters to the merge command,
> or is it better to just describe the definitive merge points in
> terms of the commit messages?

The command can take either.  Here's how it works.

If I say, hypothetically, 

   merge :1234,:5678

the expression on the right evaluates to a two-element selection set.  The
merge goes from the earlier to the later commit.  Similarly if I write

   merge <2010-10-18T11:46:55Z!guest at foobar.com>,<2011-08-18T11:42:03Z>

though this form is preferable because, while marks can become displaced
by a renumber operation, references by date should always be good unless
a date is explicitly edited after the reference is written down.  (It is
not necessary to append the submitter unless there are multiple commits with
the same time/date.)

OTOH, if I write 

   merge /I am a merge source commit/|/I am a merge target commit/

what's actually happening is a bit subtler.  Each // is a text search
that yields a selection set.  With the '|', I form the union of the
two selection sets. If both text searches refer to unique different
commits, the result is a two-element set; otherwise merge throws an
error.

The date/time and text-search forms are most stable under repo
surgery.  The text-search form is IMO easiest to understand.  I
normally use it, falling back to date/time if I can't identify unique
comment text to key on.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>