git-svn SVN 1.7 fix, take 2

[Michael G Schwern <schwern@pobox.com>]

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