On Thu, Nov 5, 2015 at 12:11 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. The contradictory case of git --progress whatever --no-progress (or viceversa) was going to be my follow-up question. Dude, don't get too far ahead in the conversation :-) 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???). > 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. Sounds interesting and in-topic (different direction). You got a list of those paths that I could work on? At least a couple you can think off the top of your head? Cause I can't complain about the progress I get on the workflows I follow (although I could keep a closer look to try to catch some operation I know is taking place and is not showing any progress and I'm used to it and so I don't complain at the lack of progress). Right now I'm thinking about cherry-picking... sometimes it can take a few seconds (or more seconds.... you have to see the performance of some of the boxes that I work on) and getting some progress there would be nice. Will take a look at it. Nice way to get familiarized with the code, by the way. Thank you very much, Junio! -- 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