[Nut-upsdev] Mixed-commit problem solved

[Eric S. Raymond]

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

http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz

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?
--
						>>esr>>