On 2024-01-11 09:04, Jeff King wrote:
On Wed, Jan 10, 2024 at 06:45:49PM +0100, Dragan Simic wrote:
4) As a careful git user that remembers important things, you go back
to your git configuration file and set core.verboseAdvice to true, and
the additional advices are back, telling you how to disable the
unwanted advice.
5) After you disable the unwanted advice, you set core.verboseAdvice
back to false and keep it that way until the next redundant advice
pops up.
However, I do see that this approach has its downsides, for example
the need for the unwanted advice to be displayed again together with
the additional advice, by executing the appropriate git commands,
after the above-described point #4.
Right, the need to re-trigger the advice is the problematic part here,
I
think. In some cases it is easy. But in others, especially commands
which mutate the repo state (like the empty-commit rebase that started
this thread), you may need to do a lot of work to recreate the
situation.
I apologize for my delayed response.
Yes, recreating some situations may simply require an unacceptable
amount of work and time, making it pretty much infeasible in practice.
Let's see what it would look like with the granular, per-advice on/off
knobs:
1) You use git and find some advice useful, so you decide to keep it
displayed. However, the additional advice about turning the advice
off becomes annoying a bit, or better said, it becomes redundant
because the main advice stays.
2) As a result, you follow the additional advice and set the specific
knob to false, and voila, the redundant additional advice disappears.
Of course, it once again isn't perfect, as the next point will clearly
show.
3) You keep using git, and one of the advices that you previously used
to find useful becomes no longer needed. But, what do you do, where's
that helpful additional advice telling you how to turn the advice off?
4) Now you need to dig though the manual pages, or to re-enable the
additional advices in your git configuration file, perhaps all of them
at once, while keeping a backup of your original settings, to restore
it later. Then, you again need to wait until the original advice gets
displayed.
These steps (3) and (4) seem unlikely to me. These are by definition
messages you have seen before and decided to configure specifically (to
"always", and not just "off"). So you probably only have a handful (if
even more than one) of them in your config file.
Yes, the number of such messages shouldn't, in general, get out of hand
over time. Though, different users may do it differently.
Whereas for the case I am worried about, you are exposed to a _new_
message that you haven't seen before (and is maybe even new to Git!),
from the much-larger pool of "all advice messages Git knows about".
It's possible we could implement both mechanisms and let people choose
which one they want, depending on their preferences. It's not very much
code. I just hesitate to make things more complex than they need to be.
Perhaps having both options available could be a good thing. Though,
adding quite a few knobs may end up confusing the users, so we should
make sure to document it well.
