Re: [PATCH v2 11/13] remote-hg: force remote push

From: Jed Brown <jed@59a2.org>
Date: Apr 4, 2013, 22:27 UTC
Message-ID: <87eheqq6dk.fsf@59A2.org>
In-Reply-To: <CAMP44s16NcTBLWuUR9bb6KaspJYYcfsWVyF9NVO4gxP-gXr4WA@mail.gmail.com>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 7 quoted lines

> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown <jed@59a2.org> wrote:
>>
>> Then perhaps we have different goals [1].  I don't know any Git User that
>> would prefer to have an Hg upstream accessed through remote-hg.
>
> Who cares? If you don't know somebody, does that mean such person
> doesn't exist?

Maybe I wasn't explicit enough:

    I don't know any Git User that would prefer to have an Hg upstream
    accessed through remote-hg *than to have a Git upstream accessed
    through native Git.*

>> We have
>> to assume that every Git (remote-hg) User is dealing with Hg Team
>
> No, we don't.

Really?  If there is no Hg Team, why bother with an Hg upstream?

> If you are always going to do Mercurial workflows, then what's the
> point of using Git?

Using Git workflow locally while being able to interact with the Hg Team via whatever conventions they have established. Sane branching, merge strategies, rerere, and a host of other Git features are plenty useful, even when contained within your personal repo.

Show 7 quoted lines

> Wow, catastrophic. BTW. Any commit pushed will show in 'hg log' either
> way. And who will run 'hg heads' if, according to you, the project has
> stated that new heads should not be pushed? If no new heads are
> pushed, 'hg heads' will never show anything interesting.
>
> Is that the *HUGE* problem? Too many heads will show in the arcane 'hg
> heads'?

Hg displays warnings about multiple heads, suggests that you merge them
any time they are anonymous, and doesn't have remote namespaces so that
names can collide.  Remember that the most common reason people give for
using Hg in the first place is that it's "simpler" (yeah, I don't agree
either, but that's their story).  So don the hat of a Git (remote-hg)
User: You're interacting with people that don't understand version
control very well and only know the basic Hg command set.  Do you really
think it's okay to silently put them in a state where Hg will print
confusing messages about multiple heads, disrupt their workflow ('hg
log'), and suggest that they do things that are likely to be disruptive
(like merge those heads)?

I've spent the last five years as an active contributor to an Hg-based project and throughout that time, newer contributors would constantly get flustered over things like this and I would get the emails asking what happened and how to fix it. Over that five year period, several other Hg projects that I was involved in switched to Git. My statements about what is likely to be acceptable to an Hg upstream is based on my experience with these projects and with a couple remaining Hg holdouts (scientific applications that I support through libraries). In none of those projects would a force push have been acceptable.

Show 5 quoted lines

>>> And who says we are committing upstream?
>>
>> The discussion is moot if you don't want to push your commits upstream.
>
> There are so many workflows and use cases you are completely ignoring.

Examples? I'm just summarizing the workflows that I encounter and that other contributors to gitifyhg encounter. You have said yourself that you don't actually use remote-hg [1], so why are you so confident that you know what workflows are desirable to remote-hg users?

> Anyway, I'm not going to discuss with you any more, a configuration
> option would work perfectly, and curiously you didn't comment on that.

Sorry, defaults matter and project philosophy matters. The fact that we are arguing about such basic things has convinced me that I can't recommend remote-hg because I have no confidence that the behavior will be remotely acceptable to a Git user working with an Hg Team.

My primary project switched to Git three weeks ago and there is already less confusion, despite having adopted a master/next/topic branch workflow that only two of us were familiar with prior to the switch. For this reason, I no longer have a vested interest in remote helpers so I don't intend to debate this issue further.

But please try to make tools for actual users rather than hypothetical users, or at least don't act so incredulous when people are less than thrilled about using or contributing to your project.

[1] http://article.gmane.org/gmane.comp.version-control.git/219988