Michael G Schwern <schwern@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html