Re: [PATCH v4] mergetool: new config guiDefault supports auto-toggling gui by DISPLAY

[Junio C Hamano <gitster@pobox.com>]

Tao Klerks <tao@klerks.biz> writes:

> If you get it wrong, an inconvenient or even bad
> thing happens: If you're in a GUI context and you forget to say
> `--gui`, then you get the CLI tool - not the end of the world, you
> might argue. If you're in a non-GUI context and you say `--gui`, you
> get a (hopefully intelligible) error about not finding a display, or
> worst case, you hang - and git doesn't know what happened, the
> messaging has to assume you aborted explicitly.

The worst case I can think of is if you have a machine that allows a
persistent virtual graphical session (remote desktop).  You can go
there, open a terminal and create a screen session, which captures
the $DISPLAY in effect.  You may disconnect from the screen session
before you disconnect from the remote desktop.  As the remote
desktop is persistent, the $DISPLAY would be valid even after you
disconnect from there.

Then you ssh into the machine and connect to the screen session.  If
you say "xterm &" in that screen session, a new window with a
terminal will open and be shown on that remote display session,
which you cannot see until you reconnect to the remote desktop.
Running "git mergetool --gui" would be the same.

With the proposed patch, the experience would become even worse in
that scenario, I am afraid.  "git mergetool" (without "--[no-]gui")
would detect the presense of $DISPLAY and start a GUI mergetool that
you cannot view or interact with ;-).  You need to explicitly say
"git mergetool --no-gui" in such a case to force use of cli tool.

Even with that caveat, I think the proposed behaviour would be a net
improvement.  I almost always work in non-GUI environment, but I can
see many people work in both and depending on their environment wish
to use the best tool for the situation.

> If there were a way to get git to autoselect "--gui" by presence of
> the DISPLAY, as it does for the *default* mergetool, then this kind of
> flow would be much more intuitive, usable, etc.
>
> I'm not sure whether I'm explaining better, or just repeating myself,
> so I'll stop here :)

Hopefully your explanation was clear enough.  Others may be able to
offer solution better than "look at DISPLAY and choose --[no-]gui
when neither is given from the command line", but I think at least I
understand your motivation behind this change.

Thanks.