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

Charles Bailey [off-list ref] writes:

On Tue, Aug 14, 2012 at 12:07:26AM -0700, David Aguilar wrote:

quoted

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?

On Tue, Aug 14, 2012 at 08:06:56AM -0700, Junio C Hamano wrote:

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.

It could be, although this certainly wasn't considered in the original
design. I know that we removed explicit references to /dev/tty and
replaced them with exec n>&m juggling which made things generally more
robust and allowed some basic shell tests to work more reliably. I
don't object to handling non-interactive mode better but it feels
unsatisfactory to only be able to resolve some types of conflict and
have to skip others.

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?

To be honest, I wasn't sure what David's issue was, other than "I
spotted this could/should it be fixed?". Is it a real world issue?

Charles.