git mergetool, merge.tool, merge.guitool and DISPLAY

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