Re: Error using git-remote-hg

[Felipe Contreras <felipe.contreras@gmail.com>]

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