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

[Peter Williams]

On 26/08/09 23:16, Augie Fackler wrote:
>
> On Aug 26, 2009, at 5:45 AM, Peter Williams wrote:
>
>>>> 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>
>>
>
> Those bugs look like they're annoyances, but not actually harmful to
> user data.

For one of them, it depends what you do with your hooks.

For the other, I'm not sure how harmful it is but there seems to be an 
implication that the wrong ancestors are being used in the merge and 
this could lead to unexpected changes to the code especially if no 
conflict is severe enough to invite human intervention.

> If I'm wrong, that seems to me a perfect argument for not
> even considering this patch until those bugs are fixed, as we'd be
> encouraging users to destroy their work.

Yes, holding it back is probably a good idea.

Similarly, qsave shouldn't be removed from mq until rebase is fixed either.

>
>> 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.
>
> Sure, it's a little easier for mq users - but you could tell them about
> rebase in the docs instead, and actually *teach* them something about
> rebase in the process.
>
> In any case, if it does get included, I'd rather it be called qrebase
> than qreparent - it seems to me it should be called what it does.

Which is reparent the patch series :-).

>
> Alternatively, have you thought of having mq add a --mq flag to rebase?
> That's what hgsubversion does for rebase, and I think it works pretty well.

Yes, I have thought of that (or something similar) but was holding it as 
a possible compromise solution.  Typing '--mq' is a lot better than 
typing '--base qbase' or '--source qbase' whichever is most appropriate 
(it's hard to tell as rebase's documentation is a bit sparse on the 
subject).  It still leaves the mq user worrying about rebase options 
which are irrelevant to them.

It's also a bit sparse on the topic of whether the --dest option is 
compulsory and, if not, what strategy rebase uses to determine the 
destination if the --dest option is omitted.  Does it use the same 
strategy as update?  Or what?

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

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