Re: About global --progress option
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 --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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About global --progress option
On Thu, Nov 5, 2015 at 12:11 AM, Junio C Hamano 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About global --progress option
Edmundo Carmona Antoranz 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
About global --progress option
Hi, everybody! Coming back from my patch about the --[no-]progress option for checkout (it's already in next, J), I'd like to build into the idea of the single --[no-]progress option for git as a whole. So, in order to know what/how things should be developed, let's start with a tiny survey 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? Thanks in advance. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
