[PATCH] [mq] addchangegroupe finalize mq patches if changeset children are added

[David Pierre-Yves]

On 13 mars 11, at 11:40, Martin Geisler wrote:

> Dirkjan Ochtman <dirkjan at ochtman.nl> writes:
>
>> On Sun, Mar 13, 2011 at 10:53, Martin Geisler <mg at lazybytes.net>  
>> wrote:
>>> I don't think that is supported, though I can see how that is
>>> annoying if you are used to rsync'ing your repository to another
>>> machine with patches applied.
>>
>> What about that isn't supported? If you mean that we don't support
>> pulling from a repo that has MQ patches applied, sure, but it might
>> still happen.
>
> Yes, I meant that if you publish mq patches, then the cease to be mq
> patches and start being real changesets (they are always real  
> changesets
> in the source repository, it is the recipient who cannot tell that  
> they
> are also mq patches.)
>
>> FWIW, in an informal survey last night both Benoit and Peter seemed  
>> to
>> think we should abort these cases (where we pull descendants of
>> MQ-managed changesets), not finish them.
>
> Right -- and I suggested that we could even go to the other extreme  
> and
> qimport the changesets that we pull as children of the existing mq
> patches. With lots of 'hg strip' and 'hg commit --close-branch', two
> persons might be able to push/pull mq patches like that. Sort of like
> with the dead heads.

I'm -1 for that. Hiding such suspicious case as "your mq patches exist  
somewhere else" with automatically conversion of standard changeset to  
mq patch will have the same issue than rebasing public repository.

Moreover in several case, it won't works. The situation describe by  
the graph below can't be resolved that way.
"*" are pulled, "x" and mq patches, "o" are standard changeset

* x
|/
x
|
x
|
o


-- 
Pierre-Yves