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