Charles Bailey wrote: > On Mon, Apr 21, 2014 at 09:59:52PM -0700, David Aguilar wrote: > > [Cc:ing Charles in case he has an opinion, this behavior dates back to the original MT] > > > > On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote: > > > It's annoying to see the prompt: > > > > > > Hit return to start merge resolution tool (foo): > > > > > > Every time the user does 'git mergetool' even if the user already > > > configured 'foo' as the wanted tool. > > > > > > Display this prompt only when the user hasn't explicitly configured a > > > tool. > > > > I agree this is probably helpful. > > Most users I've met end up configuring mergetool.prompt=false. > > From my memory, the reason that we choose to prompt by default is to > help new users or users who have just changed their choice of mergetool. > > Because we never use the exit code of the tool to determine whether a > tool "worked", if we don't prompt and the tool fails (bad custom > command, requires X when no X available, etc.) then we'll repeatedly run > the command for all paths requiring resolution leading to, potentially, > a lot of trace with whatever error the tool might happen to report. > > We prompt by default to give users a chance to abort the mergetool > session at the first opportunity that they see that the configured tool > is not working. This is what I get when a tool is not working: Documentation/config.txt seems unchanged. Was the merge successful? [y/n] > 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. -- 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