It's post OSCON so I can take another crack at this again.
I'm struggling with how best to present all this to you folks. There's
etiquette for how one presents a git pull request... but there's conflicting
etiquette about how one presents patches to a mailing list. I'm not sure
which bit of which applies when here. Documentation/SubmittingPatches focuses
on single patches and basic commit etiquette.
A big one is "do not blast 10 emails to a mailing list" but I gather that's ok
here if a submission needs 10 commits to be well expressed and its done via
git-send-email? And then if patch #3 needs revision I'm to do it in a rebase
and resend the whole 10 commits? Am I to think of git-send-email less as a
means of sending patches to a mailing list and more as a git transport mechanism?
I'm trying to bust it up into easier to digest pieces. I came into this cold
without much knowledge of the problem ("something to do with
canonicalization") and no knowledge of the code. While each commit is sharp,
the work as a whole is mixed up.
Here's the first pieces, as I see them, along with their branches. The whole
work is in https://github.com/schwern/git/tree/git-svn/fix-canonical
* Change the Makefile.PL so it automatically finds the .pm files.
https://github.com/schwern/git/tree/git-svn/easier_modules
(Going to remove the Error.pm movement as off-topic)
* Extract each of the internal Git::* packages from inside git-svn.
https://github.com/schwern/git/tree/git-svn/extract_classes
There's five classes, and I did each in at least two commits. First is a
straight cut & paste with no further changes. Second (or more) fixes it so
things work again. This is better for review (if it were done in a single
commit the real change would be lost in the cut & paste), but it means you
have a commit that breaks thing which will be a problem for bisecting. I'm
inclined to stick with two commits and you folks can squash them if you decide
bisecting is more important.
The Git::SVN extraction is more complicated than the rest, so I'll probably do
that separately and bust it up into a few commits.
Next I'm going to...
1) Submit easier_modules.
2) Break up the Git::SVN fix into more commits.
3) Submit the Git::SVN extraction.
--
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html