On Tue, Aug 14, 2012 at 10:23 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. That makes sense. Perhaps a tcl/tk dialog could be used for these when a special flag, e.g. "--interactive-gui" or something, is supplied. I think that would be nice, and I can look into this when I have some more tcl/tk hacking time. I did have a real-world example -- a GUI that runs git-mergetool on the user's behalf that (wrongly) assumed that "git mergetool -y" would not block waiting for input. This is not a problem with the documentation or with the implementation -- it was simply an oversight on my part. Due to backwards-compatibility concerns, the only way to do this (and work across as many git versions as possible) is to detect these special cases -- submodules, symlinks, and deletions -- and handle it in the calling app instead of delegating to mergetool. There is a part of me that thinks that "--no-prompt" should really not prompt, and that the various choices could be supplied on the command-line, e.g. "git mergetool --theirs --no-prompt <path>". Flags like --ours and --theirs would be heavy hammers when run without pathspecs. Nonetheless, would it would be helpful to have these? I seems like it would be helpful when resolving these special-case merge scenarios. So I think I'll take the advice that the calling app should special-case these for existing git versions, and then later allow them to fall through to mergetool once we've had a chance to add a matching GUI interface. Thanks for the sanity check, -- David -- 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