Re: Fix git-svn for SVN 1.7
- From
- Eric Wong <normalperson@yhbt.net>
- Date
- Jul 31, 2012, 20:01 UTC
- Message-ID
- <20120731200108.GA14462@dcvr.yhbt.net>
- In-Reply-To
- <5017AB63.6080909@pobox.com>
Michael G Schwern <schwern@pobox.com> wrote:
Show 6 quoted lines
> 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.
Show 5 quoted lines
> 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.