Re: What should mergetool do with --no-prompt?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 14, 2012, 15:06 UTC
Message-ID: <7vehn98qcv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120814071823.GA21031@hashpling.org>

Charles Bailey <charles@hashpling.org> writes:

Show 22 quoted lines

> On Tue, Aug 14, 2012 at 12:07:26AM -0700, David Aguilar wrote:
>> Right now there are two code paths, resolving deletion conflicts
>> and resolving symlink conflicts, in git-mergetool that do not
>> honor --no-prompt.  They force user-interaction with the shell
>> even though the caller (such as a program) said that they do
>> not want to be prompted.
>> 
>> This was an oversight from when this option was first added.
>> 
>> I think a simple and sensible thing to do would be for mergetool
>> to skip over these entries when --no-prompt is supplied.
>> 
>> Does this sound like a good idea?
>
> --no-prompt is designed to remove the prompt before launching a
> mergetool. This is because it is mostly pointless but does provide a
> convenient point to interrupt (C-c) a large multifile conflict
> resolution.
>
> It was never supposed to be a batch mode switch. By it's very nature
> mergetool is interactive so I don't see any advantage to pretending
> otherwise.

Could it be that the calling user or script does not even have a terminal but still can spawn the chosen mergetool backend and interact with the user via its GUI? Or it may have a terminal that is hard for the user to interact with, and the prompt and "read ans" may get stuck.

In such an environment, the ideal behaviour for the "git mergetool" frontend may be not to interact via the terminal at all and instead run its interaction to choose the resolution using a matching GUI interface. I see when "read ans" fails (e.g. the standard input to the mergetool is closed), resolve_{symlink,deleted}_merge will not get stuck but instead fail, so perhaps David's issue could be solved by running "git mergetool --tool=... </dev/null" or something?