On Thu, Mar 31 2022, Garrit Franke wrote: > On Wed, Mar 30 2022, Junio C Hamano wrote: > >> Sorry, but it is unclear why it is a good thing. > > My main motivation behind this change was a standardized user > experience across tools. Many users use these shorthands out of habit > to get an overview of a program. Seeing the command fail and having to > retype it in a longer form creates unnecessary friction between the > user and the program. I think this is a good trade-off in this case. I.e. -v and -h are commonly understood. >> Again, it might be safe right now, but it also closes the door for >> introducing global "verbose" option. What in exchange are we >> gaining? Are these short options worth it? > > I definitely see your concerns. Ultimately it's a question of which of > the two flags would be more convinient to have as a shorthand. As > stated above, users unfamiliar to the software arguably expect to see > the version number printed when using this flag. A user who seeks more > verbose output is probably more familiar with the options, so they are > more likely to know they have to use the longer "--verbose" form. This was somewhat discussed in/around https://lore.kernel.org/git/87zgs593ja.fsf@xxxxxxxxxxxxxxxxxxx/, i.e. there I was arguing the counter-point, that we should have things like "git --no-progress subcmd <opts>", rather than just "git subcmd --no-progress <other-opts>". But I think the alternative won the day (at least in that commit-graph case), and in retrospect I think it was the right call for our UI in general. I still think it makes sense for git to understand a thing like --object-format at the top-level, and maybe/probably --progress, but --verbose is probably too confusing. I.e. it would imply verbose output for all commands (which they're much less likely to have/provide than the other two).
