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