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

[Charles Bailey <charles@hashpling.org>]

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.