On Fri, Sep 9, 2022 at 7:07 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Tao Klerks <tao@xxxxxxxxxx> writes: > > > 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? Thanks for the quick feedback! I don't think that promise was then, or is now, broken. The behavior without `--gui` is to always use the merge.tool (and never the merge.guitool). That is in fact my complaint - that I believe there should be an auto-selection of merge.tool or merge.guitool, depending on the DISPLAY variable, when neither `--gui` nor `--no-gui` have been specified. My proposed behavior would be different to the current and original behavior, for users that have added a merge.guitool to their config in the meantime. If DISPLAY-sensitivity had been added at the time (before any users had a merge.guitool) it would have been a safe change without change in behavior for existing users, but now that some users do already have a merge.guitool, that is no longer the case. > 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. Excellent, I agree. My concern then is whether this behavior should be placed behind a new config switch, to avoid surprising users who might have come to expect the current (in my opinion suboptimal) behavior, or whether invoking the merge.guitool instead of the merge.tool, when there is a merge.guitool of course and the DISPLAY is set, would be a net improvement even for those users and should just be implemented.
