[Nut-upsdev] Mixed-commit problem solved
Eric S. Raymond
esr at thyrsus.com
Sat Jan 7 00:34:01 UTC 2012
Well, that wasn't as nasty as I feared it would be. Turns out that in
the general case it's possible to partition a mixed-branch revision
into branch cliques and generate multiple import-stream commits, one
for each affected branch.
We lose only if the split commit is the source of a later directory
copy; I have a check for that that says, basically, "if you see this
fatal error, file a bug report". The NUT repo doesn't do that. I'll
be a bit surprised if I ever get such a bug report.
The results look a little kludgy. The NUT Subversion commit r87 turns
into two git commits with Fossil-ID headers 87.1 and 87.2. The commit
corresponding to 87.2 has its commit time bumped by 1 second so all
the committer/timestamp pairs will remain unique. But it will do.
2.0-pre6 and auxiliary files have been uploaded to
for your inspection. Remaining issues:
# 1. Have yet to find a clean merge point for any branch.
# 2. set-eol-style operations get lost; see tags windows-set-eol, reset-eol.
# 3. Should the first Eaton_SDK commit after the deleteall have a link
# back to trunk?
# 4. Is the new_UIs-root tag still useful? It doesn't seem to point
# at an actual branch.
Also, some remaining zero-fileop commits on the root branch should
probably be tagified.
>From what you said before, point 2 may actually be a non-issue.
Should I cross it off the list?
More information about the Nut-upsdev