change/delete conflicts and explicit merge tools

Martin von Zweigbergk martinvonz at google.com
Fri Nov 13 11:09:59 CST 2015


On Fri, Nov 13, 2015 at 1:44 AM Siddharth Agarwal <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.


> (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
> https://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151113/84acdcf6/attachment.html>


More information about the Mercurial-devel mailing list