On Tue, Apr 22, 2014 at 01:53:46AM -0500, Felipe Contreras wrote: > 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? > I didn't remember off hand, but checking the mergetools directory suggests that kdiff3 is one (there's no call to check_unchanged). I stopped checking after I found one. > 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. I think that you may have misunderstood me. As I said, I've no particular objections to changing the default (subject a few concerns that may or may not still apply). Having said that, the fact that the user has configured the merge tool doesn't mean that he necessarily doesn't want to see the prompt. In a part of my reply which you snipped, I said that it's sometimes the particular file that's due to be resolved that might prompt a user to want to skip launching the tool. Either way, I think we shouldn't unconditionally override an explicitly set mergetool.prompt and if we are (effectively) changing the default we should probably update the documentation to say so as well. (Yes, I didn't introduce the first "no prompt" option patch and yes, I have since changed my mind about whether I have it set, but that's just a personal preference.) -- 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