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

On Thu, Apr 4, 2013 at 4:27 PM, Jed Brown [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown [off-list ref] wrote:

quoted

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

Yes, Git users prefer Git, how are such obvious statements advancing any point?

quoted

quoted

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?

Say, I push my stuff to Bitbucket, and tell my team to pull from
there. Bitbucket also has support for pull requests, so I push to
Bitbucket tons of branches, and then issue pull requests through the
web interface.

Making assumptions about how people's workflows only segregates users.
There is always a way to make it work for *everybody*.

quoted

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

They have to merge those heads *anyway*. The only question is who and when.

And of course this is a total red-herring, you are not answering the
question at all. Newbies don't run 'hg heads', and they don't have to,
there's no problem with a branch specific for bookmarks. None
whatsoever.

quoted

quoted

quoted

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?

Because I've used them in the past, and because I see Bitbucket, and
because I have eyes.

quoted

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.

Yes defaults matter, and forcing the push is the only sane default,
there is no other way to push bookmarks in Mercurial. Period.

If your team has a problem with it, you turn it off, problem solved.

And ultimately it doesn't matter what I say, we are in a public
mailing list where Junio can pick anybody's patches, even if I object.
But you have to prove your point, and you haven't. And be honest, you
not recommending remote-hg has nothing to do with the quality of it,
or the "philosophy" of it, it's simply because you made a different
choice, and you are emotionally attached to it.

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.

By people you mean you. Nobody else has complained.

-- 
Felipe Contreras