change/delete conflicts and explicit merge tools

Siddharth Agarwal sid at less-broken.com
Fri Nov 13 07:49:13 UTC 2015


I'm working on moving change/delete conflicts into the resolve phase. 
I'm wondering how to deal with backwards compatibility here.

The only tools that can be used on change/delete conflicts are :local, 
:other, :fail, and :prompt.

Consider the case where someone runs

hg merge --tool :merge

or

hg merge --tool <some-external-tool>

Currently, we prompt for change/delete conflicts even if an explicit 
tool is specified. (Naturally, since the change/delete conflict 
resolution isn't part of the filemerge process). This also means that 
for non-interactive merges with the above command line we will pick 
'changed' and continue with the merge, rather than fail it. If the only 
conflicts are change/delete ones, we will actually succeed with the 
merge! (I think this current behavior is broken.)

With moving these conflicts into the resolve phase, we have two options:

(a) continue to prompt for change/delete conflicts
(b) warn that the chosen tool cannot handle change/delete conflicts, and 
fail the merge

(a):
+ retains current behavior for change/delete conflicts -- no behavior change
- current behavior is broken in my opinion.
- doesn't follow established precedent for symlink and binary conflicts, 
where we fail the merge rather than fall back to the :prompt tool.

(b):
+ fixes broken behavior
+ follows established precedent for symlink and binary conflicts
- significant behavior change for change/delete conflicts, where some 
merges that would have succeeded in the past now fail
+ ... but in retrospect they should have failed anyway.

As you can probably tell, I'm leaning towards (b). But I'd like to make 
sure that's the right path forward here.

Followup questions:

1. What about HGMERGE? This acts like --tool: for symlink/binary 
conflicts we fail the merge rather than prompting.

2. What about the ui.merge config? This is weird: if this is a 
first-class tool (defined in merge-tools) we check to see if the tool 
supports symlink/binary conflicts. Otherwise we treat it like --tool or 
HGMERGE and fail the merge.

Here's a table describing behavior with symlink and binary files. 
'choose' here means we move ahead with the merge tool, and fail if the 
tool doesn't support that kind of conflict. 'fallback' means we look for 
another tool, falling back to :prompt if we can't find any other tools.

    config         |     behavior
    --tool         |      choose
    HGMERGE        |      choose
ui.merge, tool    |     fallback
ui.merge, command |      choose
   merge-tools     |     fallback
   merge-patterns  |  choose if binary, fallback if symlink
'hgmerge' in PATH |     fallback


More information about the Mercurial-devel mailing list