Tao Klerks <tao@xxxxxxxxxx> writes:
> 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.
We've had merge.tool almost forever but merge.guitool is a more
recent invention in late 2018.
> 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"
60aced3d (mergetool: fallback to tool when guitool unavailable,
2019-04-29) says something interesting:
The behavior for when difftool or mergetool are called without `--gui`
should be identical with or without this patch.
So, either we broke that promise since then, or the above commit was
already broken, or the tool was already broken before that? In any
case, I do not think of a good reason why configured .guitool is not
automatically honored and .tool ignored when we know we are in an GUI
environment. In other words, the choice of the tool should probably
go like:
are we in GUI? (determined by an explicit --gui, --no-gui, or env)
if so
pick one from configured .guitool (or from the fallback default
list of tools)
else
pick one from configured .tool (or from the fallback default
list of non-GUI tools)
I would think.
> 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??
