Edmundo Carmona Antoranz <eantoranz@xxxxxxxxx> writes: > Which would be the correct development path? > > - Two-step process: First step, implement global --[no-]progress at > the git level and also support the option from the builtins that > laready have it. Let it live like that for some releases (so that > people have the time to dump using the builtin option and start using > the global option) and then on the second step dump the builtin > options and keep the global one. > > or > > - A single step that would remove --[no-]progress from all builtins > that support it and would place it as a global git option? Assuming by "dump" you mean "removal of support", I doubt either is correct. Existing users know that the way to squelch progress output from their "git clone" is with "git clone --no-progress". Introducing another way to say the same thing, i.e. "git --no-progress clone" is one thing, but I do not see what value you are adding to the system by breaking what they know has worked forever and forcing them to use "git --no-progress clone". Why should they learn that the "--no-checkout" option for example has to come after "clone" and the "--no-progress" option has to come before? Why should they adjust their scripts and their finger memory to your whim? Besides, I am not convinced that you are bringing in a net positive value by allowing "git --no-progress clone". You would need to think what to do when you get two conflicting options (e.g. should "git --no-progress clone --progress" give progress? Why?), you would need to explain to the users why the resulting code works the way you made it work (most likely, "do nothing special") when the global one is given to a command that does not give any progress output, and you would need to make sure whatever answers you would give to these questions are implemented consistently. And you would need more code to do so. It is unclear to me what value the end users get out of all that effort, if any, and if the value offered to the end users outweigh the added complexity, additional code that has to be maintained, and additional risk to introduce unnecessary bugs. A lot more useful thing to do in the same area with a lot smaller amount of effort would be to find an operation that sometimes take a long time to perform that does not show the progress report and teach the codepath involved in the operation to show progress, I would think. -- 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