git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: "Rubén Justo" <rjusto@gmail.com>, "Git List" <git@vger.kernel.org>
Subject: Re: [PATCH 0/3] allow disabling the automatic hint in advise_if_enabled()
Date: Tue, 09 Jan 2024 14:32:20 -0800	[thread overview]
Message-ID: <xmqq8r4yf897.fsf@gitster.g> (raw)
In-Reply-To: <ZZ2QafUf/JxXYZU/@nand.local> (Taylor Blau's message of "Tue, 9 Jan 2024 13:28:57 -0500")

Taylor Blau <me@ttaylorr.com> writes:

> On Tue, Jan 09, 2024 at 04:25:32PM +0100, Rubén Justo wrote:
>> Using advise_if_enabled() to display an advice will automatically
>> include instructions on how to disable the advice, along with the main
>> advice:
>>
>> 	hint: use --reapply-cherry-picks to include skipped commits
>> 	hint: Disable this message with "git config advice.skippedCherryPicks false"
>>
>> This may become distracting or "noisy" over time, while the user may
>> still want to receive the main advice.
>>
>> Let's have a switch to allow disabling this automatic advice.
>
> I reviewed this and had a couple of notes, mostly focused on what to
> call the new configuration option, and if we should be modifying the
> test-tool helpers to accept arbitrary configuration via command-line
> options.
>
> I think that we could reasonably drop the first two patches by
> imitating the existing style of t0018 more closely, but I don't feel all
> that strongly about it.

Even though I do not have a fundamental objection against test-tool
learning "-c key=val", I do not see a strong need for the first two
steps, either.

I actually have more problems with the primary change of this series
(in addition to that configuration knob is probably misnamed, as you
pointed out).  How to disable the advice is an integral part of the
end-user experience about the conditional advice system.  The idea
is to show it repeatedly, perhaps loud enough to be called "noisy",
so that the user learns to follow the suggestion given by the hint.
Until then, the user is expected to gradually learn to follow the
suggestion more and more, seeing the advice message less and less
often.  If we rob the "how to disable THIS PARTICULAR message" and
gave only this line:

>> 	hint: use --reapply-cherry-picks to include skipped commits

it would become impossible to find how to disable it, once the user
get comfortable enough to pass --reapply-cherry-picks when it is
appropriate to do so.  I do not think there is no quick way other
than grepping in the source to find that the user needs to disable
the skippedCherryPicks message (no, you can look at the output from
"git config --help" and find "skippedCherryPicks" if you know that
is the symbol to be found, but there is nothing to link the above
hint message to that particular help page entry).

I would understand if the proposed change were to change the
"advice.<key>" configuration variable from a Boolean to a tristate
(yes = default, no = disabled, always = give advice without
instruction), though.  IOW, the message might look like so:

    hint: use --reapply-cherry-picks to include skipped commits
    hint: setting advice.skippedCherryPicks to 'false' disables this message
    hint: and setting it to 'always' removes this additional instruction.

Then, those who find the hint always useful (because the particular
mistake the hint is given against is something the user commits very
rarely and the convenience of being reminded when it happens, which
is rare, outweigh the burden of learning what is suggested) may want
to set it to 'always' to accept that new choice.

But not the way the new feature is proposed.

Thanks.

  reply	other threads:[~2024-01-09 22:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-09 15:25 [PATCH 0/3] allow disabling the automatic hint in advise_if_enabled() Rubén Justo
2024-01-09 15:29 ` [PATCH 1/3] t/test-tool: usage description Rubén Justo
2024-01-09 18:19   ` Junio C Hamano
2024-01-09 15:29 ` [PATCH 2/3] t/test-tool: handle -c <name>=<value> arguments Rubén Justo
2024-01-09 18:19   ` Junio C Hamano
2024-01-09 18:20   ` Taylor Blau
2024-01-09 15:30 ` [PATCH 3/3] advice: allow disabling the automatic hint in advise_if_enabled() Rubén Justo
2024-01-09 18:23   ` Junio C Hamano
2024-01-09 18:27   ` Taylor Blau
2024-01-09 19:57     ` Junio C Hamano
2024-01-10 12:11     ` Rubén Justo
2024-01-10 11:02   ` Jeff King
2024-01-10 11:39     ` Rubén Justo
2024-01-10 14:18     ` Dragan Simic
2024-01-10 14:32       ` Rubén Justo
2024-01-10 14:44         ` Dragan Simic
2024-01-10 16:22           ` Junio C Hamano
2024-01-10 17:45             ` Dragan Simic
2024-01-11  8:04               ` Jeff King
2024-01-18  6:15                 ` Dragan Simic
2024-01-18 18:26                   ` Junio C Hamano
2024-01-18 18:53                     ` Dragan Simic
2024-01-18 20:19                       ` Junio C Hamano
2024-01-18 20:50                         ` Dragan Simic
2024-01-20 11:31                           ` Rubén Justo
2024-01-20 15:31                             ` Dragan Simic
2024-01-10 16:14     ` Junio C Hamano
2024-01-09 18:28 ` [PATCH 0/3] " Taylor Blau
2024-01-09 22:32   ` Junio C Hamano [this message]
2024-01-10 12:40     ` Rubén Justo
2024-01-12 10:05 ` [PATCH] advice: " Rubén Justo
2024-01-12 22:19   ` Junio C Hamano
2024-01-13  7:38     ` Jeff King
2024-01-16  4:56       ` Junio C Hamano
2024-01-15 11:24     ` Rubén Justo
2024-01-15 14:28   ` [PATCH v2] " Rubén Justo

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=xmqq8r4yf897.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=rjusto@gmail.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.
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 NNTP newsgroup(s).