On 3/15/2020 7:59 PM, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> If the parser that kicks in before the commands do their own parsing >> needs to know that much to correctly understand "--progress" anyway, >> wouldn't the same amount of effort would allow us to teach these >> individual commands to understand "--progress" and pass it correctly >> down to the underlying helpers? >> >> So, "git clone --no-progress" that lets checkout progress may be a >> bug worth fixing, but I do not think a global switch is a good way >> forward. > > You can sort-of work it around by introducing "--[no-]progress" that > is taken as an option to the "git" command, just like "--[no-]pager" > is, to work around the issue above. But I have a feeling that you > did not like the resulting UI, which is totally backward incompatible > and break users' existing scripts and habits. > > The resulting UI built around "git --[no-]progress subcmd" may feel > much nicer, and I suspect that it would be something we would have > picked, if we had today's experience back when we started adding > progress display to individual subcommands. > > As long as a clear transition path can be drawn, I do not > necessarily object to such a direction that (1) introduces the > global level "git --[no-]progress $subcmd" option, and (2) > deprecates and eventually removes the "--progress" option at the > subcommand level. I think a way to compromise is to create an OPT_PROGRESS() macro that starts as a weak wrapper around the current OPT_BOOL() that is used with most builtins manually adding --[no-]progress. Then, it can be updated to do a more advanced action upon seeing --progress or --no-progress to set GIT_PROGRESS as described. This would allow builtins to easily integrate --[no-]progress into their command-line parsing without issues as you described. Thanks, -Stolee
