From: Junio C Hamano <gitster@pobox.com>
To: "Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Tao Klerks <tao@klerks.biz>
Subject: Re: [PATCH v2] RFC: mergetool: new config guiDefault supports auto-toggling gui by DISPLAY
Date: Fri, 14 Oct 2022 08:45:43 -0700 [thread overview]
Message-ID: <xmqqczaube8o.fsf@gitster.g> (raw)
In-Reply-To: <pull.1381.v2.git.1665734440009.gitgitgadget@gmail.com> (Tao Klerks via GitGitGadget's message of "Fri, 14 Oct 2022 08:00:39 +0000")
"Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> writes:
> * In git-mergetool--lib.sh the way I implemented the "auto" special
> value means that if you put an arbitrary value in the config, eg the
> typo "uato", you get an error about it being an invalid boolean
> config value; is that OK? Is there a better way to handle "boolean or
> special value" config validation? Are there any examples?
I think the ideal behaviour would be:
* Unless running difftool and difftool.guiChoice has a wrong value,
or running mergetool and mergetool.guiChoice has a wrong value,
we should not even complain.
* If the command line says --gui or --no-gui that makes the setting
irrelevant, it is OK for us to give a warning to remind the user
that they may want to fix the spelling of the variable, but
otherwise go ahead and perform the action as they asked us to.
* If the command line lacks --gui or --no-gui, we do need to have a
usable value in the configuration, and we should error out
without spawning either gui or no-gui tool backend.
It may be usable without the second one and always fail difftool and
mergetool until the setting gets fixed, but that is less than ideal.
We do allow less than ideal code in, as long as it is an improvement
over the status quo, and its presence does not make it harder to
later get closer to the ideal.
Thanks.
next prev parent reply other threads:[~2022-10-14 15:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 15:59 [PATCH] mergetool: new config guiDefault supports auto-toggling gui by DISPLAY Tao Klerks via GitGitGadget
2022-10-12 16:08 ` Tao Klerks
2022-10-12 18:12 ` Junio C Hamano
2022-10-13 6:49 ` Tao Klerks
2022-10-13 21:58 ` Junio C Hamano
2022-10-14 4:53 ` Tao Klerks
2022-10-14 9:10 ` Junio C Hamano
2022-10-14 12:32 ` Tao Klerks
2022-10-14 15:37 ` Junio C Hamano
2022-10-16 20:07 ` Tao Klerks
2022-10-14 8:00 ` [PATCH v2] RFC: " Tao Klerks via GitGitGadget
2022-10-14 8:24 ` Eric Sunshine
2022-10-14 9:11 ` Tao Klerks
2022-10-14 15:45 ` Junio C Hamano [this message]
2022-10-16 20:19 ` Tao Klerks
2022-10-17 5:50 ` Junio C Hamano
2022-10-18 6:54 ` [PATCH v3] " Tao Klerks via GitGitGadget
2023-02-17 10:59 ` Tao Klerks
2023-03-18 15:27 ` [PATCH v4] " Tao Klerks via GitGitGadget
2023-04-04 9:46 ` David Aguilar
2023-04-04 14:50 ` Tao Klerks
2023-04-04 20:35 ` Junio C Hamano
2023-04-06 3:33 ` David Aguilar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqczaube8o.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=tao@klerks.biz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).