tracking upstream, what now?

waldemar waldemar at beechwoods.com
Sun Aug 15 17:25:48 UTC 2010


On 08/15/2010 08:48 AM, Benoit Boissinot wrote:
> On Sun, Aug 15, 2010 at 5:25 PM, Martin Geisler<mg at lazybytes.net>  wrote:
>    
>> Neal Becker<ndbecker2 at gmail.com>  writes:
>>      
>>> Martin Geisler wrote:
>>>        
>>>> Neal Becker<ndbecker2 at gmail.com>  writes:
>>>>          
>>>>> Benoit Boissinot wrote:
>>>>>            
>>>>>> It looks like a workflow where mq could be a good fit.
>>>>>> (replacing the merge part with rebase --mq)
>>>>>>
>>>>>> cheers,
>>>>>>
>>>>>> Benoit
>>>>>>              
>>>>> hg rebase --mq --help
>>>>> hg rebase: option --mq not recognized
>>>>>            
>>>> See 'hg help mq' which will tell you to enable the mq extension first.
>>>>
>>>>          
>>> Sorry if I'm doing something really stupid here, but mq is enabled (as
>>> is rebase)
>>>        
>> Ehm, sorry, my mistake! You just do the rebase like normal, with no
>> (nonexisting) --mq option. Rebase knows how to move mq patches around.
>>      
> Indeed sorry. The mq trigger is automatic when mq patches are applied.
>    

You can also just keep putting your upstream releases on a branch and 
then keep merging that branch with your other branch. We prefer this 
technique over some other mentioned before because (1) we deal with a 
wide range of mercurial users (hence trying to keep it as simple as we 
can), (2) prefer to avoid difficulties sharing mq's (we love mq's to 
shape patches before sharing but we don't share mq stacks), (3) do not 
use non-bundled extensions by the corporate writ. (but pbranch continues 
to be of interest to us if it could only establish itself a bit more)

Waldemar


> cheers,
>
> Benoit
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>    



More information about the Mercurial mailing list