From: Charles Bailey Date: Tue, 14 Aug 2012 17:09:00 GMT Subject: Re: What should mergetool do with --no-prompt? 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: > > 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=...