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.
