[PATCH STABLE] backout: make --noninteractive be noninteractive

Steve Borho steve at borho.org
Sun Nov 21 20:20:56 CST 2010


On Sun, Nov 21, 2010 at 1:39 PM, Jason Harris <jason.f.harris at gmail.com> wrote:
>
> On Nov 21, 2010, at 7:52 PM, Matt Mackall wrote:
>
>> On Sun, 2010-11-21 at 19:18 +0100, Jason Harris wrote:
>>> # HG changeset patch
>>> # User jfh <jason at jasonfharris.com>
>>> # Date 1290340736 -3600
>>> # Node ID a9dac2fb64b7ad324669f37798b3abfa3ef53086
>>> # Parent  42ac864ed3946df2a3b7b87dcbc05cd4d35a62c3
>>> backout: make --noninteractive be noninteractive
>>
>> For future reference, a much better summary would be:
>>
>> backout: make --noninteractive disable the commit editor
>
> Yep. That is a better message! Thanks!
>
>
>> Historically, noninteractive only disables ui.prompt:
>>
>> -y --noninteractive     do not prompt, assume 'yes' for any required
>> answers
>>
>> But this extension of it seems quite reasonable. However, it has
>> implications - does that then mean that:
>>
>> hg commit -y
>>
>> should now commit an empty message? That would be bad. It seems we can
>> only disable editors if we have a default message. The other command
>> that comes to mind with a default message is tag, which has a -e switch
>> to force an editor. It's different than backout, in that with backout,
>> it's usually good to explain why you're backing something out, while
>> with tag it's generally implicit in the tag name.
>>
>> Which makes me think that your GUI is trying to do something it probably
>> shouldn't: back out changesets without prompting for a reason. If it
>> were prompting, it would then be calling something like:
>>
>> hg backout -r <some id> -l '<reason>'
>>
>> and hg wouldn't launch an editor. And this of course works with current
>> hg, which is always a plus.
>>
>> So I'm not sure if we really want this. Thoughts?
>
> Good points! Thanks!
>
> Actually in MacHg, I was adding a backout sheet when I came across this in testing, and thus put in the proposed fix. It seemed like the right thing to do. But I can see the thornier points your question raises. As for an auto commit message? Maybe something modeled from the output of diffstat??  Still the idea doesn't really grab me.  Better to not allow it I think, and just simply fail.
>
> Just for reference, in MacHg you will *in fact* be able to fully customize the actual backout message (if I allow the --merge option). It would default to the fuller commit message and the user will be able to change it.
>
> so the default commit message for the backout --merge would look like:
> ----------
> Backout changeset 2345f234785
> Some original changeset message: blah blah blah
> blah blah blah
> blah blah blah
> ----------
>
> I should point out as well with the default call in hg 1.7+ to "hg backout --rev nnn" the editor is never actually invoked since the change is not automatically committed. That is the default "hg backout"  looks approximately like an export of a reverse patch, followed by "hg import --no-commit <TheReversePatch>". Thus this question of message only comes up in the "backout --merge" case. Actually I should have said this in the commit message...
>
> So in fact in MacHg I was even wondering if I should give the option of allowing a "backout --merge ..." in the first place, or just restricting backout to be a linear backout... (I am not really sure why anyone would ever actually *want* a merge backout...) and it visually complicates the interface if sometimes the commit message is there (for the --merge case) and not there for the normal case...

I struggled with this in the Qt version of the backout dialog.  In the
end, I presented the --merge option with a checkbox labeled:  Commit
backout before merging with current working parent

If the checkbox is not checked, the message pane is desensitized until
the backout is completed, at which point the dialog becomes a
simplified commit tool that also allows you to resolve merge
conflicts.

> So I would ask people the related question under what circumstances is really useful to have a "backout --merge ..." instead of a normal "backout ..."?

Some people find the undo commit more descriptive

-- 
Steve Borho


More information about the Mercurial-devel mailing list