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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html