Rethinking mq and pbranch now we have rebase

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Fri Nov 27 01:45:06 CST 2009


On Fri, Nov 27, 2009 at 7:45 AM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> On Fri, Nov 27, 2009 at 1:10 AM, Peter Williams <pwil3058 at bigpond.net.au> wrote:
>> On 26/11/09 20:26, Peter Arrenbrecht wrote:
>>>
>>> On Thu, Nov 26, 2009 at 10:46 AM, Matt Mackall<mpm at selenic.com>  wrote:
>>>>
>>>> On Thu, 2009-11-26 at 10:28 +0100, Peter Arrenbrecht wrote:
>>>>>
>>>>> On Thu, Nov 26, 2009 at 10:19 AM, Matt Mackall<mpm at selenic.com>  wrote:
>>>>>>
>>>>>> On Thu, 2009-11-26 at 09:52 +0100, Peter Arrenbrecht wrote:
>>>>>>>
>>>>>>> Folks, maybe clever use of rebase could lead to a new approach to what
>>>>>>> is currently addressed by mq and pbranch.
>>>>>>
>>>>>> You're aware that you can rebase applied mq patches and they'll
>>>>>> continue
>>>>>> to be mq patches, right?
>>>>>
>>>>> Yes, learning this is what started me thinking. Point is, why still
>>>>> keep the patches sitting around in .hg/patches? And (optionally)
>>>>> trying to version them as patch files? And enforcing linearity amonst
>>>>> them? When we can just keep them as csets with full fork/join support,
>>>>> and version them by just keeping rebase sources in the tree?
>>>>
>>>> Well mq wasn't invented in a vacuum, it's part of a long line of tools
>>>> supporting important workflows. In some of these flows, patches (rather
>>>> than changesets) are first class objects that are maintained for
>>>> significant periods of time outside of the target project.
>>>> Backward-compatibility with quilt and rpm's linear model is also quite
>>>> useful.
>>>
>>> True. But this entails consequences that are restricting and confusing
>>> to other users of mq. So I still don't see why the patches have to be
>>> the master copy.
>>>
>>> I think many mq users don't care about the external patch files.
>>
>> I do.  That's what my use of MQ is all about.  I used to use quilt but now
>> use MQ because it has better facilities for updating the patches when the
>> underlying code changes BUT it's still all about the patches.
>>
>> By the way, I think that what MQ offers justifies keeping a local Mercurial
>> conversion of the Linux git sources just so I can use it.
>>
>>> They
>>> are interested in polishing their work prior to final acceptance into
>>> a tree, or in maintaining a set of changes atop an upstream project.
>>> And their workflow could be improved by getting rid of the patch
>>> files.
>>>
>>> If people do need the patches, they could use something like a beefed
>>> up export (pbranch already has this, including the series file), which
>>> could even be automated whenever the queue changes. And we could also
>>> automate the other way, if the patches were changed externally. And
>>> these people would just have to be careful to use linear queues. But
>>> why bind everyone else to these restrictions?
>>
>> Once again, you're trying to force people to do things your way.  Extend MQ
>> by all means but leave the basics alone.  Remember that this is now
>> documented to the world in the O'Reilly book (ISBN 978-0-596-80067-3) and
>> people who read that book (justifiably) expect MQ to work as described.
>
> Relax. I'm not the one saying there is no room for multiple ways of
> managing malleable history in hg.

Alright, I'm going to relax, too. ;)

I'll start another thread asking about workflows people currently have
with mq's physical patch files.
-parren


More information about the Mercurial-devel mailing list