On Tue, Aug 14, 2012 at 10:23 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Charles Bailey <char...@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.

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,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to