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