Re: [PATCH 2/2] mergetool: run prompt only if guessed tool

[Charles Bailey <charles@hashpling.org>]

On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
> 
> This is what I get when a tool is not working:
> 
>   Documentation/config.txt seems unchanged.
>   Was the merge successful? [y/n]

Does this happen now even with merge tools for which we do trust the
exit code? If so, my original concern is addressed.

> > Personally, I leave mergetool.prompt unset (default true) because one
> > extra click in a complex merge resolution is relatively low overhead and
> > to catch myself when I forget that I'm in a no-X environment.
> > 
> > I glanced at the patch and it seems to subvert this intent for users
> > who have  configured a merge tool. Is my understanding correct?
> 
> Yes, that's correct. If the user has *manually* configured a tool, why would
> you ask him again? We are annoying the overwhelming the vast majority of users
> who already configured the right tool in order to avoid issues with a minute
> minority that might potentially but unlikely have a problem once or twice.
> 
> That's not productive.

We're asking to user to signal that he's happy to launch the mergetool
and implicitly giving him an opportunity to break out of the session.
I don't see anything wrong with having this behaviour.

So long as we don't hit the loop-with-lots-of-error-trace for users who
haven't set mergetool.prompt I've no strong objections to changing the
default so long as an explictly set mergetool.prompt is respected.

Ideally, I think I'd like the prompt to accept a "launch/skip/abort"
range of options but that's a wider scoped thing. Sometimes when I'm
resolving a lot of things and not specifying any paths I come across
something that know I don't want to attempt a resolve with my currently
configured tool and I just want to skip it for now. Currently, I have to
either abort the session or let the mergetool fire up and close it again
neither of which are optimal.