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