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
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