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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]