change/delete conflicts and explicit merge tools

[Ryan McElroy]

On 11/13/2015 9:09 AM, Martin von Zweigbergk wrote:
>
>
> On Fri, Nov 13, 2015 at 1:44 AM Siddharth Agarwal <sid at less-broken.com 
> <mailto:sid at less-broken.com>> wrote:
>
>     I'm working on moving change/delete conflicts into the resolve phase.
>     I'm wondering how to deal with backwards compatibility here.
>
>
> I was also wondering how you were planning on dealing with that :-)
>
>
>     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.)
>
>
> I agree that it's 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
>
>
> Maybe also:
>
>  (c)  leave conflicts unresolved in non-interactive mode
>
> I think we should add a "leave unresolved" option to the prompt 
> regardless, and your discussion about non-interactive mode make me 
> think that that should be the default.

I really like the "leave unresolved" option -- it is actually really 
important, in my opinion, to be able to have a "persistent" unresolved 
state for all conflicts -- meaning that I can take several attempts to 
resolve it using, perhaps, different tools for each conflict (which 
implies that that unresolved state can persist over multiple invocations 
of mercurial). We already have this state for file/file conflicts, but I 
want it for all types of conflicts so I can examine the situation before 
being forced to make a decision.

I think allowing this persistent unresolved state will actually make the 
rest of the decisions easier -- tools that can't handle a particular 
conflict simply won't be given a particular conflict to resolve (with a 
warning, similar to (b)). Particularly, is I run `hg merge --tool foo` 
and foo cannot handle non-file conflicts, the non-file conflicts remain 
unresolved, with a warning, and the merge does not complete. This is 
natural and allows the user to proceed using other tools instead of 
being forced to make decisions s/he is not sure about.

>
>
>     (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
>     _______________________________________________
>     Mercurial-devel mailing list
>     Mercurial-devel at selenic.com <mailto:Mercurial-devel at selenic.com>
>     https://selenic.com/mailman/listinfo/mercurial-devel
>
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151113/31f70b0a/attachment-0001.html>