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
More majordomo info at

Reply via email to