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

Peter Williams pwil3058 at bigpond.net.au
Wed Aug 26 05:45:38 CDT 2009

On 26/08/09 16:15, Peter Williams wrote:
> On 26/08/09 10:17, Augie Fackler wrote:
>> On Aug 25, 2009, at 7:42 AM, 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.
>>>  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.
>>> 'Reparenting' the qbase sounds rather silly...
>>> An entirely different question is whether it is a good thing
>>> to make the mq extension dependent on the rebase extension.
>>> Which is probably a much bigger issue than the name of the
>>> proposed new command.
>> Honestly, I'm -1 on having:
>> 1) yet another obscure mq subcommand that very few will use
> The users of mq for whom it was originally intended would use this a
> lot.  The fact that mq has uses beyond its original design intent is a
> good thing but mq shouldn't be crippled so that it only meets the needs
> of these new users.
>   From my Point of view, things such as guards and patch versioning are
> obscure (and I've never even contemplated using them) but you don't see
> me suggesting that they should be removed.
>> 2) reinventing the wheel
> It's not a case of reinventing the wheel.  It's a case of reusing the wheel.
>> when we can just state somewhere in the
>> {mq,rebase} docs that you can do (eg) hg rebase -s qtip -d tip and it'll
> Would that actually do the desired thing.  I'm not sure on the exact
> semantics of -s/--source (and -b--base for that matter) (because the
> documentation is so poor) but wouldn't that only move the top patch and
> leave the rest where they are?
>> magically DTRT even though there's an mq, since rebase is already mq safe.
> Rebase is NOT mq safe and there are at least 2 outstanding bug reports
> that support this statement.
> <http://mercurial.selenic.com/bts/issue1561>
> <http://mercurial.selenic.com/bts/issue1807>

I should have added here that I'm confident that these bugs will be 
fixed and that rebase will become mq safe.  After all, qreparent relies 
on rebase being mq safe and that it will DTRT (so while rebase is broken 
so is qreparent).  It's just a different (more mq user oriented) way of 
invoking rebase. It's not a replacement for rebase. It's not 
disrespecting rebase.  It's just making its use easier for mq users.

Also, although it adds a command to mq (which seems to be a sin), it's 
in anticipation of others (including qsave) being removed.

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