What's next for pbranch?

[Christian Boos]

Peter Arrenbrecht wrote:
> On Wed, Nov 25, 2009 at 3:05 PM, Christian Boos <cboos at neuf.fr> wrote:
>   
>> Peter Arrenbrecht wrote:
>>     
>>> On Wed, Nov 25, 2009 at 6:56 AM, Peter Williams <pwil3058 at bigpond.net.au>
>>> wrote:
>>> [snip]
>>>
>>>       
>>>> That doesn't mean that MQ doesn't have its uses.  For its intended
>>>> purpose,
>>>> keeping a set of local patches against an externally managed source tree
>>>> (e.g. the Linux kernel), it is superior to pbranch.
>>>>
>>>> And I'm sure that for some purposes pbranch is superior to MQ.
>>>>
>>>>         
>>> Actually, for the specific case you mention I personally find pbranch
>>> to be superior. I use it to maintain a set of local patches against hg
>>> crew, for instance. Unlike mq pbranch uses regular hg merges for
>>> updating the patches against changes in upstream.
>>>
>>>       
>> Note that with Mercurial 1.4, you can now safely use 'hg rebase' for
>> rebasing your MQ patch queue.
>> This *will* use regular hg merges for updating the patches against changes
>> in upstream.
>>
>> e.g. assuming you have your patch queue applied:
>>
>> $ hg pull
>> $ hg rebase -b qtip -d tip
>>     
>
> Welcome news. Nevertheless, pbranch keeps full history of the merges,
> whereas mq's rebase will lose it. And pbranch records which version of
> patches were supposed to apply to which version of upstream. This, not
> even versioned mq will tell you without ad-hoc measures like encoding
> current qbase into the commit msgs of your .hg/patches repo.

I see. Yes, having mq to at least record the last known good qparent 
somewhere would be good.

>  And versioned mq is not something for the faint of heart, anyway.
>   

Neither is pbranch ;-)

-- Christian