Junio C Hamano wrote: > It is time to catch regressions by asking wider audiences who do not > normally follow Git development (i.e. those who are not the ones that > follow 'master' and rebuild/install it once or twice a week for their > daily use). And you have one of those regressions in Git v2.0. > My understanding is that versions of remote-hg shipped with all > versions of Git did not work with Hg 3.0, so 58aee08 is not a > regression fix at all. Is working with Hg 3.0 at such a high priority > that it makes it worth to slip the whole release schedule by a few > weeks? I do not think so. It is in the contrib/ area, you don't need to slip the schedule for something that is not part of the core. Moreover, it *CANNOT POSSIBLY INTRODUCE REGRESSIONS*. I bet my reputation on that. Some time ago I asked you to trust my judgement and introduce changes late into a release, and I told you there wouldn't be any problems, and to trust me. If any problems arise I wouldn't be asking for something like that again. Well, I was right, there were no problems. And I'm right this time too, there would be no issues. But you don't care about reality and facts. You don't care about the intent behind the release-candidates rule, you would rather follow the rule blindly. > Regarding the commit in question, I asked Felipe a question and > never got a straight answer. Nor will you get one, because thanks to your stupid decision for which you still haven't provided a rationale, the git-remote-hg and git-remote-hg are no longer maintained in git.git. If you hadn't made such a move, you would have your answer, the fix would be properly explained, the regression fixed, and all your users would be happy that git-remote-hg and git-remote-bzr get distributed by default. -- Felipe Contreras -- 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