Junio C Hamano wrote: > Felipe Contreras <felipe.contre...@gmail.com> writes: > > > And you are still conveniently avoiding the question: > > > > Based on what reasoning? > > Go re-read what was already said in the thread.
I already read it, and I already responded. > I still think remote-hg and remote-bzr can and will flourish on their > own merit, Oh, you *think*. Well, what if you are wrong? Or is that never a possibility? You are always right. Right? > Having said that, I've been thinking (not because of this thread, > but because I like imerge better and better these days) that there > should be a much better way to have a list of recommended third-party > plug-ins that enrich the Git ecosystem. If and when such a mechanism exists, sure, it makes sense to move functionality like git-p4 and git-remote-hg out of the core and contrib areas. But in the meantime what is ready for the core should be in the core. > > Normally I would explain the details of why this is the case, and send > > the crash regresion fix for v2.0 with a clear explanation,... > > Without such an explanation in the log message, how would you expect > anybody to guess correctly? I don't. I told you it wasn't a mistake. If that's not enough for you, that's *your* problem. *If* git-remote-hg was to be part of the core, then sure, I would care that you didn't understand why the patch is correct, and I would resend immediately what a clear explanation. But since it's only part of the contrib area which has such abundant crap without documentation or tests. I do not care. > Seriously, if you do not care about my first reaction, why do you > even want to live in my tree? As I already explained; I don't care about your reaction *because* you don't want these tools to live in your tree. > > The fact that I'm the maintainer and I say it'ss good should be good > > enough, and if the current version in "master" renders unusable the > > existing Mercurial clones, hey, it's only in contrib, right? > > One potential merit I would see for keeping them in my tree is that > your change will see second opinions from others involved in the > project (including me), without giving a total rein based on the > sub-maintainership alone. All the changes from sub-area maintainers > are vetted by at least two sets of eyeballs that way. > > But after having to deal with you and seeing that you do not take > constructive criticism well, Oh, please. Up to the point where you decided unilaterally to move them out of the core (they are alread in), all the constructive criticism to git-remote-hg has been addressed properly. I have spent an absurdely large amount of time working on git-remote-hg, and the transport-helper to make sure everything works right. I even started git-remote-bzr just to prove that the Python git_remote_helpers framework was not needed, and eventually I made it work better than any of the alternatives. I had to fight tooth-and-nail to prove that the msysgit guys were wrong and my patch to handle UNINTERESTING refs properly was right. Not to mention all the tests, the compatibility with hg-git, and with gittifyhg, just to prove that my approach was superior than the alternatives. I addressed every issue reported constructively, every bug report was fixed, every patch reviewed and usually improved by me. I made sure users of older versions wouldn't be affected negatively when the marks file was upgraded, and I even setup automatic tests for different versions Bazaar and Mercurial that run every time I push to my repository. It is *way* beyond the quality of any other tool in 'contrib/' and even some tools in the core, like 'git-request-pull' (which has known bugs), and probably even 'git-pt'. Even you agreed it would be beneficial to move them out of contrib; it would benefit *everyone*. And there was no reason not to. And then some random guy comes with a few bad arguments, and you change your mind. That's f*cking double standards. Pure and simple. If git-remote-hg belongs out-of-tree, so does git-svn and git-p4. If git-remote-hg belongs in the contrib area, so does git-svn, and git-p4. After all this insane amout of work you are acting as if git-remote-hg wasn't ready to move to the core, because I didn't explain *one* commit properly to you (which happened after this bullshit). If these helpers are not going to move forward why would I care? Give me why one good reason why I should give a flying f*ck about the state of remote-helpers in *your* tree after this (and BTW as things stand now, it's not good). It was *your* users who urged me to send my patches upstream. > I doubt such a possibile merit will ever materialize in the area where > you alone work on. And there it is. Ad hominem rationale. > Letting you do whatever you want in your own tree may benefit the > users of remote-hg/remote-bzr better as the (bitter) second best > option. If and when there is a mechanism promoting out-of-tree tools, that might be the case. In the meantime virtually every tool that is worth using lives in git.git and is distributed by default. Everything else is sub-par in the minds of Git users. One tool being dropped from the tree while other tools remain there is not going to send a positive message to its users. If you are so confident git-remote-hg would "flourish" out-of-tree, drop git-p4 and git-svn, see what is the reaction. -- Felipe Contreras -- 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
