Rethinking mq and pbranch now we have rebase

[Peter Williams]

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.

Peter