[Nut-upsdev] git conversion progress

[Charles Lepple]

On Jan 21, 2012, at 4:58 PM, Eric S. Raymond wrote:

> Charles Lepple <clepple at gmail.com>:
>> I may have spoken too soon. Some of the branches are subtly wrong.
>> 
>> In particular, the apparmor branch was created from the trunk, not windows_port.
>> 
>> Also, the history of the tl_usb_fbsd branch is not terribly important, but it also has a "merge bubble" at the "Working on uhid driver again" commit.
> 
> Aaargh.  I'll look into this.
> 
> It would be really useful if I had a *complete* topology defect report.


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. Usually, that comes in the form of "here's a new version of the code to test", which may or may not introduce problems that are orthogonal to the previous set of problems. 

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.

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". 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). 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.

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?

-- 
Charles Lepple
clepple at gmail