On Tue, Jan 7, 2020 at 8:44 PM Emily Shaffer <emilyshaffer@xxxxxxxxxx> wrote: > On Tue, Jan 07, 2020 at 08:34:04AM -0800, Junio C Hamano wrote: > > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > > > (It is rather verbose and ugly, though.) > > > > I tend to agree. It also feels to me that it is giving too much > > hand-holding, but after all advise() may turning out to be about > > giving that. > > Well, if advise() isn't going to hold their hand, who is? ;) > What I mean is, I think that's indeed what advise() is about, and the > reason it can be disabled in config. Git is already drowning in configuration options. Every new option increases the complexity level for the user and of Git overall, requires additional code, additional tests, and additional documentation, and must be maintained for the life of the project. So, every configuration option carries a cost in terms of end-user experience and developer resources. If anything, we should be trying to keep the number of configuration options constant (or, even better, reduce it), rather than forever adding more. Thus, we should think very hard before adding any new configuration option, trying instead to discover ways in which an issue can be addressed without adding a configuration option (with its attendant costs and complexity), and only add an option as a last resort. > To me, the harm of giving too much hand-holding seems less than the > harm of giving not enough; to deal with the one requires skimming > past things you already know [...] Perhaps I'm too old-school and too steeped in The Unix Way, but there is value in silence and conciseness, and that value outweighs chattiness, especially when chattiness is effectively unnecessary (which is the case in the vast majority of error/warning messages emitted by Git). Too much hand-holding quickly becomes noise which gets ignored, thus eventually drowns out the really important information. People need to understand a problem before taking action to solve it. Blindly following some piece of advice without understanding a problem can lead to further problems (especially in those cases when it's not possible to devise advice which suitably covers all situations in which a particular problem may arise). A well-written, clear, _concise_, error message can often provide enough information to allow the user to understand and resolve the problem without additional hand-holding. It's true that there are some complex situations (for instance, detached HEAD) for which additional hints can be handy for newcomers or casual users, but that should be the exception, not the norm. Rather than adding advice messages for every possible problem, perhaps a better use of our time would be to weed out poorly-worded and unhelpful error messages and improve them.
