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

From: Charles Bailey <charles@hashpling.org>
Date: Aug 14, 2012, 17:09 UTC
Message-ID: <20120814170900.GA28978@hashpling.org>
In-Reply-To: <7vehn98qcv.fsf@alter.siamese.dyndns.org>

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

Show 6 quoted lines

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

Show 7 quoted lines

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