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

[Junio C Hamano <gitster@pobox.com>]

Charles Bailey <charles@hashpling.org> writes:

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

Exactly.  The mention of "a matching GUI" below you quoted was a
suggestion to improve that "only resolve some but not others"
problem.  The usual mergetool backend, e.g. meld, may not be capable
of resolving symlink conflicts, but "git mergetool" could run a GUI
dialog that gives the user "ours/theirs/fail" choice (or better yet
"merge result value" textbox in addition) for such a path.  The same
for delete/modify conflicts.

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