This is an archive of the discontinued Mercurial Phabricator instance.

resolve: add option to warn/abort on -m with unresolved conflict markers
ClosedPublic

Authored by spectral on Aug 1 2018, 4:49 PM.

Details

Summary

When a user is dropped out of Mercurial to a terminal to resolve files, we emit
messages like:

conflicts while merging file1! (edit, then use 'hg resolve --mark')
conflicts while merging file2! (edit, then use 'hg resolve --mark')

We don't mention a file name in the hint, so some users might do something like
$EDITOR file1; hg resolve --mark, see that it says "(no more unresolved
files)" and forget to deal with file2 before running the next command.

Even if we did mention a file name in the hint, it's too easy to forget it
(maybe the merge spans a couple days or something). This option lets us inform
the user that they might have missed something.

In the scenario above, the output would be something like:

warning: the following files still have conflict markers:
  file2
(no more unresolved files)

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

spectral created this revision.Aug 1 2018, 4:49 PM

I like the idea here. @khanchi97 is already working on adding --confirm to hg resolve, how about having something like hg resolve --mark --confirm which asks you before marking each file as resolved?

In D4035#62542, @pulkit wrote:

I like the idea here. @khanchi97 is already working on adding --confirm to hg resolve, how about having something like hg resolve --mark --confirm which asks you before marking each file as resolved?

My primary goal is that hg resolve --mark be made safer. The exact mechanism isn't too important to me :) If this involves a --confirm mode that can be defaulted to on, preferably with an auto-confirm-if-no-markers-detected, that's fine with me. If it requires explicit opt-in on the commandline (instead of being something that can be turned on with a config), I don't think that it would accomplish the same safety improvement.

pulkit added a comment.Aug 1 2018, 5:55 PM
In D4035#62542, @pulkit wrote:

I like the idea here. @khanchi97 is already working on adding --confirm to hg resolve, how about having something like hg resolve --mark --confirm which asks you before marking each file as resolved?

My primary goal is that hg resolve --mark be made safer. The exact mechanism isn't too important to me :) If this involves a --confirm mode that can be defaulted to on, preferably with an auto-confirm-if-no-markers-detected, that's fine with me. If it requires explicit opt-in on the commandline (instead of being something that can be turned on with a config), I don't think that it would accomplish the same safety improvement.

Yep, I agree with you. Queued this patch, many thanks! Can you add about this on https://www.mercurial-scm.org/wiki/Release4.8? We have a section for experimental features.

This revision was automatically updated to reflect the committed changes.
pulkit added a comment.Aug 1 2018, 6:01 PM

Also, even though this is experimental, can we document it somewhere?

In D4035#62660, @pulkit wrote:

Also, even though this is experimental, can we document it somewhere?

Sure, any advice for where would be a good place to do that? I would have thought mercurial/help/config.txt, but there's nothing in there about experimental options right now.

I'm also fine skipping a prolonged 'experimental' phase and moving out of experimental now/soon. I generally default to starting things in experimental, but maybe I shouldn't be doing that, and just land things like this completely to start with? :)

pulkit added a comment.Aug 2 2018, 5:55 PM
In D4035#62660, @pulkit wrote:

Also, even though this is experimental, can we document it somewhere?

Sure, any advice for where would be a good place to do that? I would have thought mercurial/help/config.txt, but there's nothing in there about experimental options right now.

I think we need 'mercurial/help/experimental.txt' or something.

I'm also fine skipping a prolonged 'experimental' phase and moving out of experimental now/soon. I generally default to starting things in experimental, but maybe I shouldn't be doing that, and just land things like this completely to start with? :)

As Augie also mentioned this looks appropriate as non-experimental, lets move this out of experimental and hence document that.