Re: [PATCH 2/2] mergetool: run prompt only if guessed tool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> > 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.

So long as we don't hit the loop-with-lots-of-error-trace for users who
haven't set mergetool.prompt I've no strong objections to changing the
default so long as an explictly set mergetool.prompt is respected.

Ideally, I think I'd like the prompt to accept a "launch/skip/abort"
range of options but that's a wider scoped thing. Sometimes when I'm
resolving a lot of things and not specifying any paths I come across
something that know I don't want to attempt a resolve with my currently
configured tool and I just want to skip it for now. Currently, I have to
either abort the session or let the mergetool fire up and close it again
neither of which are optimal.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]