Charles Bailey wrote: > 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. Which tools are those? > > > 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. You don't see anything wrong with asking the user *every single time* he runs `git mergetool`, even though he *already told us* which tool to use? If so, I'm pretty sure everybody else disagrees with you. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html