[PATCH] mq: Add a new command, 'qrebase', to obviate need for 'qsave'

Peter Williams pwil3058 at bigpond.net.au
Wed Aug 26 01:00:44 CDT 2009


On 25/08/09 22:42, Adrian Buehlmann wrote:
> [On 25.08.2009 10:57, Peter Williams wrote:
>> I am.  But I'm using mq terminology and rebase isn't part of mq.
>
> Funny, but with your proposed patch, you exactly do that:
>
> You implicitly make rebase a part of mq by making mq dependent on
> rebase.

As an internal implementation issue.  It doesn't require rebase to be 
enabled.

>
>  From your proposed patch:
>
> On 25.08.2009 08:43, Peter Williams wrote:
>> +    from hgext import rebase
>> +    opts['base'] = 'qbase'
>> +    return rebase.rebase(ui, repo, **opts)
>
> There, you _rebase_ the qbase.
>
> BTW, how is that difficult to explain? "Rebasing the qbase"
> seems pretty clear. You rebase the queue.

Because the meaning of base in qbase is different to the meaning of base 
in rebase.  What is happening in fact is that qbase is being moved to a 
new parent.

>
> 'Reparenting' the qbase sounds rather silly...

But it more accurately reflects what's happening (in mq terminology).

And you don't say that anyway (as that's an implementation detail). 
What you say is "reparenting the patch series" and that makes perfect 
sense in mq terminology.

>
> An entirely different question is whether it is a good thing
> to make the mq extension dependent on the rebase extension.

See above re semantics of dependent.

>
> Which is probably a much bigger issue than the name of the
> proposed new command.

Since you raised the idea, I think that this is the alternative solution 
(to adding qreparent to mq) to what to do if qsave is removed from mq. 
That is, make mq dependent on rebase and have enabling mq automatically 
enable rebase (if it isn't already enabled) and add something to mq's 
documentation pointing the user to rebase as the thing to use instead of 
(what somebody, Patrick Mezard I think, eloquently termed) the qsave 
dance for updating patch sets when the underlying code demands.

But I personally think that would be a very ugly solution.

Peter
-- 
Peter Williams                                   pwil3058 at bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce


More information about the Mercurial-devel mailing list