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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html