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