Michael G Schwern <schw...@pobox.com> wrote:
> It just doesn't matter.
> Why are we arguing over which solution will be 4% better two years from now,
> or if my commits are formatted perfectly, when tremendous amounts of basic
> work to be done improving git-svn?  The code is undocumented, lacking unit
> tests, difficult to understand and riddled with bugs.

Yes it does matter.

git-svn has the problems it has because it traditionally had lower
review standards than the rest of git.  So yes, we're being more careful
nowadays about the long-term ramifications of changes.

> Either solution would be a vast improvement.  The most important thing is that
> one of them actually gets done.  If both solutions offer a huge improvement,
> do it the way the person actually writing the code wants to do it.  It'll be
> more enjoyable for them, they'll be more likely to complete the work, and more
> likely to stick around and code some more.

The self-obsoleting nature of git-svn makes it hard for anybody to stick
around.  Most of the original contributors (including myself) hardly see
an SVN repo anymore, so users/contributors forget about it and new ones
come along...

I want to make sure things stay consistent with the core parts of git,
especially if the Perl were to be replaced with a pure C version.
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

Reply via email to