On 09-ene-2024 14:32:20, Junio C Hamano wrote:
> Taylor Blau <me@xxxxxxxxxxxx> 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.
