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

[Jed Brown <jed@59a2.org>]

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

> 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.

> 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.

>>> 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