change/delete conflicts and explicit merge tools

Siddharth Agarwal sid at less-broken.com
Fri Nov 13 12:18:57 CST 2015


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).


More information about the Mercurial-devel mailing list