On Thu, Nov 05, 2015 at 12:47:22AM -0600, Edmundo Carmona Antoranz wrote: > On the technical side, I think the global --progress option (and > removing the option from the builtins) would not add complexity but > the opposite because setting the flag would be done at the "main git" > level and then all the builtins would just forget about it and would > use progress regardless (cause deciding _if_ progress should be shown > or not won't be up to them anymore) so the code from the builtins to > support the option would be gone. It would certainly be more complex > while keeping global and builtin options alive. Anyway, I do > understand your concerns and will stand down on the topic (as in.... > global --progress who???). I think you are missing one important element, which is that git programs do not all share a memory space with the main git binary. So you cannot simply set the "progress" variable in the main program and expect everybody to see it. Running "git foo" may invoke a separate "git-foo" program, written in another language entirely. For that reason, options to the main git binary typically set an environment variable which is communicated to all sub-processes. For an example, see how "--literal-pathspecs" is implemented. So it actually does add some complexity. That being said, the environment variable can be a good thing. For example, imagine I have a script "git-foo" which runs several commands, including "git-fetch". It's cumbersome for "git-foo" to take a "--progress" option and then pass that down to "git-fetch". If you could instead run: git --no-progress foo and have that flag magically propagate to any git sub-programs which care about showing progress, then that could perhaps make the feature worthwhile (I say perhaps because while it seems plausible to me, I have not heard of anyone actually wanting this feature in practice). But adding in "git --progress" is an orthogonal decision to removing support for "git <cmd> --progress". I do not see any big advantage to the latter at this point, and a lot of potential negatives as we break scripts and user expectations. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html