"Tao Klerks via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Tao Klerks <tao@xxxxxxxxxx> > > When no merge.tool or diff.tool is configured or manually selected, the > selection of a default tool is sensitive to the DISPLAY variable; in a > GUI session a gui-specific tool will be proposed if found, and > otherwise a terminal-based one. This "GUI-optimizing" behavior is > important because a GUI can make a huge difference to a user's ability > to understand and correctly complete a non-trivial conflicting merge. > > Some time ago the merge.guitool and diff.guitool config options were > introduced to enable users to configure both a GUI tool, and a non-GUI > tool (with fallback if no GUI tool configured), in the same environment. > > Unfortunately, the --gui argument introduced to support the selection of > the guitool is still explicit. When using configured tools, there is no > equivalent of the no-tool-configured "propose a GUI tool if we are in a GUI > environment" behavior. > > Introduce new configuration options, difftool.guiDefault and > mergetool.guiDefault, supporting a special value "auto" which causes the > corresponding tool or guitool to be selected depending on the presence of a > non-empty DISPLAY value. Also support "true" to say "default to the guitool > (unless --no-gui is passed on the commandline)", and "false" as the previous > default behavior when these new configuration options are not specified. > > Signed-off-by: Tao Klerks <tao@xxxxxxxxxx> > --- > RFC: mergetool: new config guiDefault supports auto-toggling gui by > DISPLAY This somehow felt somewhat familiar, so I had to go the list archive to find https://lore.kernel.org/git/xmqqmtb8jsej.fsf@gitster.g/, which seems to be the previous discussion. It would have been much easier if you gave readers the original context that inspired this design.
