Ideally we shouldn't do this, as it's not recommended in mercurial
documentation, but there's no other way to push multiple bookmarks (on
the same branch), which would be the behavior most similar to git.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file cha
Felipe Contreras writes:
> Ideally we shouldn't do this, as it's not recommended in mercurial
> documentation, but there's no other way to push multiple bookmarks (on
> the same branch), which would be the behavior most similar to git.
>
> Signed-off-by: Felipe Contreras
> ---
In the previous r
Felipe Contreras writes:
> Ideally we shouldn't do this, as it's not recommended in mercurial
> documentation, but there's no other way to push multiple bookmarks (on
> the same branch), which would be the behavior most similar to git.
The problem is that you're interacting with a Mercurial upstr
On Thu, Apr 4, 2013 at 10:44 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Ideally we shouldn't do this, as it's not recommended in mercurial
>> documentation, but there's no other way to push multiple bookmarks (on
>> the same branch), which would be the behavior most similar to git.
Felipe Contreras writes:
> On Thu, Apr 4, 2013 at 10:44 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Ideally we shouldn't do this, as it's not recommended in mercurial
>>> documentation, but there's no other way to push multiple bookmarks (on
>>> the same branch), which would be
On Thu, Apr 4, 2013 at 12:17 PM, Jed Brown wrote:
> Felipe Contreras writes:
>> Ideally we shouldn't do this, as it's not recommended in mercurial
>> documentation, but there's no other way to push multiple bookmarks (on
>> the same branch), which would be the behavior most similar to git.
>
> Th
Felipe Contreras writes:
> If that's the case, they should disable in the server, just like some
> people disable non-fast-forward pushes in git.
I don't know how to make Hg allow new branches and bookmarks, but not
new anonymous heads. Vanishly few Hg projects use a workflow anything
like topi
On Thu, Apr 4, 2013 at 2:14 PM, Jed Brown wrote:
> Felipe Contreras writes:
>
>> If that's the case, they should disable in the server, just like some
>> people disable non-fast-forward pushes in git.
>
> I don't know how to make Hg allow new branches and bookmarks, but not
> new anonymous heads.
Felipe Contreras writes:
[...]
>> will need to play by those rules.
>
> No, we don't. The fact that you say so doesn't make it so.
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. We have
to assume that e
On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown wrote:
> Felipe Contreras writes:
>
>
> [...]
>
>>> will need to play by those rules.
>>
>> No, we don't. The fact that you say so doesn't make it so.
>
> Then perhaps we have different goals [1]. I don't know any Git User that
> would prefer to have an
Felipe Contreras writes:
> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown 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
> d
On Thu, Apr 4, 2013 at 4:27 PM, Jed Brown wrote:
> Felipe Contreras writes:
>
>> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown 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?
Jed Brown wrote:
Felipe Contreras writes:
On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown wrote:
...
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?
Huh? the counterpart of "every user"
Joachim Schmitz writes:
> Jed Brown wrote:
>>
>> Really? If there is no Hg Team, why bother with an Hg upstream?
>
> Huh? the counterpart of "every user" wpuld be "some users" and not "no user"
> or "no HG team", isn't it?
I'm not sure what you're getting at here, but the whole premise of a
t
14 matches
Mail list logo