Re: [PATCH 0/4] remote-hg: more improvements

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 8, 2014, 23:39 UTC
Message-ID: <536c15cf8594b_6f3bb152ecb@nysa.notmuch>
In-Reply-To: <xmqqha4z27ly.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:

Show 8 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > I already said this multiple times, but let me be clear once more:
> >
> > MASTER HAS A REGRESSION (for all versions of Mercurial).
> 
> As you said, that is not a regression, isn't it?  It is an old
> breakage that existed even before 1.9 (was it 1.8.3 or something?)

No. It does't happen in 1.9, it will happen in 2.0.

That's a REGRESSION.

Show 11 quoted lines

> >> If you no longer want to have it in contrib/, I can drop it in future
> >> releases (but not in v2.0), so that people can find the latest and
> >> greatest directly from you.  Otherwise, queuing a fix on 'pu' and then
> >> to 'next' in preparation for an early graduation for the release after
> >> v2.0 (and as a fix, it may want to go to older maintenance releases)
> >> is also fine by me.
> >
> > Are you saying that the graduation plan is going to continue and they
> > are going to move out of contrib and be distributed by default?
> 
> I do not think that is going to happen.

Then I don't understand what you mean by "graduation".

> As we discussed already, I do see merit in unbundling it from my tree.

You are blind. Move git-p4 and git-svn out of your tree.

You know what will happen.

> I can keep it in contrib/ as that is a slight benefit for you

What is the benefit of being in contrib/? Even you yourself argued that there is not much point of 'contrib/' nowadays[1]. The only reason we might want something in contrib/ is so that it has a chance to mature before becoming part of the core.

> (i.e. you can be lock-step with Git) but as long as you live in my
> tree, you need to follow the same release schedule as the other
> contributors, which may be detrimental to your users, compared to a
> case where it is unbundled.

It's much more beneficial to *our* users if these tools are distributed by default.

> I do not see a strong reason to move it out of contrib, either.

Really? So why did you say this?[2]

Show 5 quoted lines

> > Either way, I think if things go well, remote-hg will prove it's
> > worth and move out of contrib and into git's core.
> 
> That was what you promised when we started carrying it in contrib/; I
> am still hoping to see it happen when it matures.

Jeff said the same thing when he was acting as maintainer[3], and you didn't correct him:

> I would one day like to have it as part of the main distribution, too,
> but it would be nice to prove its worth in the field for a while
> first.

All this time I've been operating under the impression that once git-remote-hg proved itself, it would graduate out of contrib.

So basically you tricked me, and I wasted insane amounts of time chasing a target that was impossible to reach.

Fuck this.

[1] http://article.gmane.org/gmane.comp.version-control.git/220178 [2] http://article.gmane.org/gmane.comp.version-control.git/220277 [3] http://article.gmane.org/gmane.comp.version-control.git/208648

-- 
Felipe Contreras