Improving git-svn documentation

While diving into the git-svn code, I realized that many things could be done to make it more documented/understundable. I need to get more understanding of it, so I'd like to improve this state of things. But first, I'd like to be sure there is a consensus on what is a good idea to do, since that could easily turn up into a lot of textual change.

- (on the user doc side of things) some options appear not to be
  documented (I spotted --parent for 'clone' and --revision for
  'dcommit').  But looking at where to document them, I found it not
  always easy, since some options are documented together with the
  command they modify, some others in the "options" section (even when
  they are documented as applying to a single command, like --shared
  or --stdin).  This IMHO leads to confusion for the user looking for
  information, as well as to the reviewer trying to check that nothing
  was forgotten.  I would rather make that only very commons are
  described in a common "options" section, and that all commands using
  them explicitely say so in their descriptions (with xref).

- (on the code side of things) git-svn.perl weights more than 5500
  lines, most classes functions and methods severely lack
  documentation, and some extensively-used variable names are so short
  they make the code harder to grasp

  Eg. $gs to refer to an instance of the Git::SVN class, which I would
  suggest to change to something like $gsrepo, while at the same time
  renaming Git::SVN to eg. Git::SVN::Repository - which would make it
  much easier for a newcomer to grasp what this is supposed to
  represent - supposing, that is, that my understunding of this part
  is accurate enough, which it is probably not after spending many
  hours in there :)

  As to the size of the file, it seems natural to me to split the
  classes into their own files.  That would still let git-svn.perl and
  the Git::SVN class to be 1500-lines tall, the largest others
  achieving around 500 lines.  That should be much more manageable
  pieces, and would require some refactoring wrt a couple of global
  variables used throughout the script; which, incidentally, could
  make it much easier to simultanously look at several git-svn
  repositories (for my work on mapping externals to submodules), and
  to allow reusing the existing code, eg. as a git-vcs backend.

How are you people feeling about this rough plans ?