Re: [PATCH 0/3] allow disabling the automatic hint in advise_if_enabled()

["Rubén Justo" <rjusto@gmail.com>]

On 09-ene-2024 14:32:20, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:

> that configuration knob is probably misnamed, as you
> pointed out).

Agree.  Maybe we have a better name: "showDisableInstructions".

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

That's an interesting twist ... and intuitive it seems, as Peff also
came up with a similar approach.

But do we need, or want, that fine grain?

Using advise_if_enabled() allows us to display a hint while
automatically adding the option to disable it, _explicitly_ (so far*),
to the user.

But it happens that advise_if_enabled() itself has a hint to give.

My goal in this series is about giving the user the possibility to
disable _that_ hint (in the hint).

The user choosing to disable that hint is telling us: "I know I can
disable a hint, stop telling me so, please".  So I don't think
this opens up a new risk or problem finding how to disable a hint.

    $ git -c advice.showDisableInstructions=1 command_with_a_no_longer_welcomed_hint

Is there a need to make that "hint in the hint" customizable _per hint_?

That probably means that a new "make-it-always-for-all" may be desirable
alongside the new tristate yes-no-always ...

I dunno.


    * perhaps this multi-value possibility could be a path
      to explore what Taylor outlined in another message in this thread:
      the possibility of a "one-shot" hint.