On Thu, Apr 4, 2013 at 4:27 PM, Jed Brown <jed@xxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown <jed@xxxxxxxx> 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.*
Yes, Git users prefer Git, how are such obvious statements advancing any point?
>>> 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*.
>> 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.
>>>> 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.
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html