On 2012.7.31 1:01 PM, Eric Wong wrote: > 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. Yes, review does matter. And so far we've been arguing over whether reviewing objects-with-overloading or objects-without-overloading would be better. And we can argue about that forever. That's the part that doesn't matter. People matter. I think we can all agree that either solution is a vast improvement along multiple axes, including review. So what really matters is making sure one of them gets done. Once either of them is done, we can see how it works out in practice instead of arguing theoretical futures. Once either of them is done, it's much easier to switch to the other. What I'm trying to say is I have much less interest in doing it without the overloading. It's not interesting to me. It's no fun. No fun means no patch. No patch means no improvement. No improvement is the worst of all possible options. I had a lot of enthusiasm for this project when I came in. I like refactoring Perl code. I like git. That's all but sunk at how painful and slow and nit-picking the process has been. We've barely talked about the content of the patches I've submitted, it's all process. This is no fun. We're all volunteers here and we're all getting something personal out of this. Some form of personal enjoyment. I'm not getting that, so I'm unlikely to stick around. -- Defender of Lexical Encapsulation -- 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