[Nut-upsdev] git conversion progress

[Charles Lepple]

On Jan 23, 2012, at 9:37 PM, Eric S. Raymond wrote:

> Charles Lepple <clepple at gmail.com>:
>> Hmm, I still see the wrong content in the final
>> scripts/augeas/*.aug.in, although the merge from Augeas into the
>> trunk is not indicated. (That merge point on the last pass was
>> correct, IMHO - but the final merged *.aug.in files should have
>> @CONFPATH@ instead of /etc/nut after the trunk merge - see my
>> previous email.) Tested with commit c023d35 to reposurgeon.

Per your other email, I was using c023d35 in reposurgeon, plus d5cfc7ec in nut-reposurgeon.

When I was testing with 147ce9ee in reposurgeon (one before c023d35), I saw SVN commit 2781 expressed as an Augeas-to-trunk merge. With c023d35, it is no longer indicated as a merge in the nut-git output, but there is still a problem with the file contents as described below.

> Then we've probably got a two-point failure, with some bug or metadata
> problem unrelated to the merge.  I stupidly assumed that since you
> were reporting content from the wrong side of the merge, filtering
> out the invalid merge would do the trick.  Now I suspect there's
> something funky happening on the trunk side.

It's slightly more nuanced than "wrong side of the merge" - more like something from the middle of the Augeas branch. Here's a breakdown of the events (with SVN revision numbers):

trunk at 2367: Before Augeas branch was created, there was no scripts/augeas/ directory.

Augeas at 2368: Looks like a server-side copy created the branch (no fileops)

Augeas at 2373: Added initial versions of scripts/augeas/*.aug (with hardcoded paths to /etc/nut)

Augeas at 2769: The scripts/augeas/*.aug files are renamed to scripts/augeas/*.aug.in, with autoconf-style substitutions.

Augeas at 2780: Merge from trunk at 2779. At this point, the *.aug.in files still look good, and the reposurgeon trunk-to-branch merge looks okay.

trunk at 2781: Merge from Augeas at 2780. This commit seems to get the contents of the *.aug files (but stored in the *.aug.in files) from before Augeas at 2769 (badness ensues)

> And it really was an invalid merge - copy of a subdirectory rather than the
> entire branch.  Well...semantically it was a valid merge, but one that
> can't be expressed in gitspace.  We may run into more of those.


This is one aspect of the git fast-import stream that I still can't seem to wrap my head around. Git represents each revision as a set of files in time, with the only file "history" being the topology of the commits themselves. A merge commit, as I understand it, should simply be a snapshot of the files after they were merged. It is up to front-end tools like gitk to reconstruct the three-way diff or perform rename detection when requested.

-- 
Charles Lepple
clepple at gmail