git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Tao Klerks <tao@klerks.biz>
To: Junio C Hamano <gitster@pobox.com>
Cc: Tao Klerks via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2] RFC: mergetool: new config guiDefault supports auto-toggling gui by DISPLAY
Date: Sun, 16 Oct 2022 22:19:22 +0200	[thread overview]
Message-ID: <CAPMMpohWE17xk4fF+uQja0jfn53bjgVtg75FKEC1w0Km7U8Dvg@mail.gmail.com> (raw)
In-Reply-To: <xmqqczaube8o.fsf@gitster.g>

On Fri, Oct 14, 2022 at 5:45 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "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.

This is how it behaves right now, yes.

>
>  * 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.

In the current implementation, there is no warning if the choice has
been explicitly made - there is no reason to check the configured
default under such circumstances.

>
>  * 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.

This is *not* the current behavior - currently an error is printed,
but execution continues with a no-gui default. I will correct this.

>
> 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 for the logic table, sounds good.

However, my concern was with the precise form of the error if a
configured value is neither trueish, not falseish, nor a case-tolerant
form of "auto": under such circumstances, instead of a dedicated error
message along the lines of "fatal: bad config value 'autod' for
'difftool.guidefault' - must be boolean or 'auto'", we get the
*default* error message for *boolean* config settings: "fatal: bad
boolean config value 'autod' for 'difftool.guidefault'". This can of
course be corrected, I just need to work out how, and exactly what
form the error message should then take.

Should we be elaborating an error message for this specific tristate
config value, or is it "normal" fail with a slightly-misleading
message suggesting it is a simple boolean config in such cases?

Thanks,
Tao

  reply	other threads:[~2022-10-16 20:19 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
2022-10-16 20:19     ` Tao Klerks [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPMMpohWE17xk4fF+uQja0jfn53bjgVtg75FKEC1w0Km7U8Dvg@mail.gmail.com \
    --to=tao@klerks.biz \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).