Hi folks,
I've just become aware today of what *seems* like a very strange
discrepancy or limitation in "git mergetool":
When you use it without having configured a "merge.tool", it
auto-selects the first available tool from a predefined list, which
appears to be hardcoded in "git-mergetool--lib.sh", with some
conditions around "$DISPLAY", "$GNOME_DESKTOP_SESSION_ID" and
"${VISUAL:-$EDITOR}".
In this "auto-selection" situation, no GUI-based merge tool will be
offered/selected if you're not in a GUI session.
When you configure your tools, you can configure "merge.tool" for the
default, and "merge.guitool" for GUI contexts - so far so good, sounds
consistent.
However, once you've configured these two settings, "git mergetool"
will never select the GUI tool you've configured unless you very
*explicitly* tell it to, by specifying the --gui argument. The
sensible auto-selection based on "DISPLAY" disappears.
The upshot, as I understand it, is that the only way to get a GUI when
I'm connected with an X session, and get a terminal-based mergetool
when I'm not, without having to be aware and issue different commands,
is to accept whatever tooling default order is hardcoded in
"git-mergetool--lib.sh"
Is this intentional / is there any logic here, or is this just
unfortunate, a result of the auto-selection evolving more
intelligently than the built-in explicit "--gui" selection, over
time??
If I wanted to improve this, what would be a more sensible approach?
* Assume "--gui" if there is a DISPLAY and "--no-gui" has not been
specified? (behavior change for some existing users)
* Add a new configuration to enable such an "auto-gui respecting
config" mode (no behavior change)
(I have not looked into "git difftool", but I assume the same
arguments and issues apply - if so an equivalent improvement would
need to be made there of course)
Thanks for any thoughts,
Tao
