Charles Bailey <charles@xxxxxxxxxxxxx> 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. -- 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