change/delete conflicts and explicit merge tools

[Pierre-Yves David]

On 11/13/2015 10:18 AM, Siddharth Agarwal wrote:
> On 11/13/15 09:21, Ryan McElroy wrote:
>> 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.
>
> Yeah, I agree that the "leave unresolved" option makes sense -- I was
> planning to add it independent of this discussion.
>
>> 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.
>
> So if I understand you correctly, you're leaning towards proposal (b)
> (fail) rather than (c) (prompt, but leave unresolved as the default).

I agree that the current behavior (a) is broken, we should not just pick 
a random side and declare the merge successful.

+1 for "leave unresolved"

I think I lean toward (c) prompt instead of (b) fail. Because requiring 
all user to got through `hg resolve --tool` seems like bad idea. This 
seems far to complicated to get basic user out of troubles, we'll loose 
people in the process.

-- 
Pierre-Yves David