This way we don't get it in the commit message, even if the patch had
been generated by cogito (or CVS, ugh) and people didn't add the proper
"---" marker.
..and git-apply does a lot better job at it anyway.
Also, we break the comment/diff on a line that starts with "diff -", not
just on the "---" line. Especially for git diffs, we actually want that
line in the diff.
(We should probably also break on "Index: ..." followed by "=====")
file versions.
This allows you to do the conversion (although slowly) from
a remote repository, and besides, it's one less thing to worry
about when you don't need to look up the CVS Attic directories
etc.
We need to quote backslash and backtick too.
And inform the user about our progress, since converting a
big archive can take time. Doing the full mutt history took
just under eight minutes.
This should also mean that the conversion is now completely
defined by the CVS tree, and that two people doing a cvs2git
conversion on the same base will always get the same results
regardless of when or in what timezone they do it.
This escapes '$' characters in <<-handling, and gives preference to
the new branch when cvsps incorrectly reports a commit as originating
on an old branch.
.. and tell 'co' to shut up about the rcs noise.
This still leaves some branch issues up in the air: it looks like
cvsps has some questionable originating branch information, but I
don't know whether that's a cvsps bug or an actual bug in the
syslinux archive I'm using to test.
I'll let David Mansfield answer my questions about CVS. I'm a
total idiot when it comes to branches under CVS ("I'm pure!").
It's very hacky, and it needs lots of work, but it seems to have converted
Peter's "syslinux" archive successfully. Whether the end result is correct
or not is to be seen.
Tons of work still to do: do name conversion properly, and do tags etc.
And testing. Lots of testing.
Now that git does pretty reliable date parsing, we might as well get
the date from the email itself. Of course, it's still questionable
whether the date on the email is all that relevant, but it's certainly
no worse than taking the commit date.
This makes "dotest" a lot nicer to sue, especially for people who were
used to editing the commit comments after-the-fact in BK, which git
doesn't apply.
he syntax is
dotest [-q] mailbox [signoff]
so the command line operates exactly as you're used to. If you supply
the -q it will query before applying (I also added the [a]pply all the
rest option). If the signoff file is absent, no signoff line gets
added.
There's also one addition in this: a checkout-cache line. I added that
for poor saps like me whose laptop takes minutes to checkout a full
build tree, so I can run dotest in a directory with no checked out
files.
My brain just flipped when it tried to read the "Applying" as part
of the explanation of the patch, and the sentence didn't make any
sense. The quotes make it clear what's going on.
I looked a bit at my old BK tools for the same thing, but they were
just so horrid in many ways that I largely rewrote it all and these
tools do things a bit differently. Instead of aggressively piping
data from one process to another (which was clever but very hard
to follow), this first just splits out the mbox into many smaller
email files, and then does some scripts on these temporary files.
