{"thread":{"id":"40725","subject":"About global --progress option","startedAt":"2015-11-05T03:13:20Z","lastAt":"2015-11-05T07:08:41Z","messageCount":4,"participants":["Edmundo Carmona Antoranz","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"272930","messageId":"CAOc6etYiGV0v4gkkpudi3ACa6kA3H8CnqYYeSksfO4mGGfEyXg@mail.gmail.com","threadId":"40725","inReplyTo":null,"subject":"About global --progress option","fromName":"Edmundo Carmona Antoranz","fromEmail":"eantoranz@gmail.com","sentAt":"2015-11-05T03:13:20Z","receivedAt":"2015-11-05T03:13:20Z","isPatch":false,"sender":{"key":"eantoranz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1491018?v=4"},"body":"Hi, everybody!\n\nComing back from my patch about the --[no-]progress option for\ncheckout (it's already in next, J!!!!), I'd like to build into the\nidea of the single --[no-]progress option for git as a whole.\n\nSo, in order to know what/how things should be developed, let's start\nwith a tiny survey\n\nWhich would be the correct development path?\n\n- Two-step process: First step, implement global --[no-]progress at\nthe git level and also support the option from the builtins that\nlaready have it. Let it live like that for some releases (so that\npeople have the time to dump using the builtin option and start using\nthe global option) and then on the second step dump the builtin\noptions and keep the global one.\n\nor\n\n- A single step that would remove --[no-]progress from all builtins\nthat support it and would place it as a global git option?\n\n\nThanks in advance.\n"},{"id":"272938","messageId":"xmqqk2px7z7h.fsf@gitster.mtv.corp.google.com","threadId":"40725","inReplyTo":"CAOc6etYiGV0v4gkkpudi3ACa6kA3H8CnqYYeSksfO4mGGfEyXg@mail.gmail.com","subject":"Re: About global --progress option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-11-05T06:11:14Z","receivedAt":"2015-11-05T06:11:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:\n\n> Which would be the correct development path?\n>\n> - Two-step process: First step, implement global --[no-]progress at\n> the git level and also support the option from the builtins that\n> laready have it. Let it live like that for some releases (so that\n> people have the time to dump using the builtin option and start using\n> the global option) and then on the second step dump the builtin\n> options and keep the global one.\n>\n> or\n>\n> - A single step that would remove --[no-]progress from all builtins\n> that support it and would place it as a global git option?\n\nAssuming by \"dump\" you mean \"removal of support\", I doubt either is\ncorrect.\n\nExisting users know that the way to squelch progress output from\ntheir \"git clone\" is with \"git clone --no-progress\".  Introducing\nanother way to say the same thing, i.e. \"git --no-progress clone\" is\none thing, but I do not see what value you are adding to the system\nby breaking what they know has worked forever and forcing them to\nuse \"git --no-progress clone\".  Why should they learn that the\n\"--no-checkout\" option for example has to come after \"clone\" and\nthe \"--no-progress\" option has to come before?  Why should they\nadjust their scripts and their finger memory to your whim?\n\nBesides, I am not convinced that you are bringing in a net positive\nvalue by allowing \"git --no-progress clone\".  You would need to\nthink what to do when you get two conflicting options (e.g. should\n\"git --no-progress clone --progress\" give progress?  Why?), you\nwould need to explain to the users why the resulting code works the\nway you made it work (most likely, \"do nothing special\") when the\nglobal one is given to a command that does not give any progress\noutput, and you would need to make sure whatever answers you would\ngive to these questions are implemented consistently.  And you would\nneed more code to do so.  It is unclear to me what value the end\nusers get out of all that effort, if any, and if the value offered\nto the end users outweigh the added complexity, additional code that\nhas to be maintained, and additional risk to introduce unnecessary\nbugs.\n\nA lot more useful thing to do in the same area with a lot smaller\namount of effort would be to find an operation that sometimes take a\nlong time to perform that does not show the progress report and\nteach the codepath involved in the operation to show progress, I\nwould think.\n"},{"id":"272941","messageId":"CAOc6etbuK7=-8kH60taO8uH+6XNGTFRNGmmkswgP-19bCRNB3Q@mail.gmail.com","threadId":"40725","inReplyTo":"xmqqk2px7z7h.fsf@gitster.mtv.corp.google.com","subject":"Re: About global --progress option","fromName":"Edmundo Carmona Antoranz","fromEmail":"eantoranz@gmail.com","sentAt":"2015-11-05T06:47:22Z","receivedAt":"2015-11-05T06:47:22Z","isPatch":false,"sender":{"key":"eantoranz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1491018?v=4"},"body":"On Thu, Nov 5, 2015 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Besides, I am not convinced that you are bringing in a net positive\n> value by allowing \"git --no-progress clone\".  You would need to\n> think what to do when you get two conflicting options (e.g. should\n> \"git --no-progress clone --progress\" give progress?  Why?), you\n> would need to explain to the users why the resulting code works the\n> way you made it work (most likely, \"do nothing special\") when the\n> global one is given to a command that does not give any progress\n> output, and you would need to make sure whatever answers you would\n> give to these questions are implemented consistently.  And you would\n> need more code to do so.  It is unclear to me what value the end\n> users get out of all that effort, if any, and if the value offered\n> to the end users outweigh the added complexity, additional code that\n> has to be maintained, and additional risk to introduce unnecessary\n> bugs.\n\nThe contradictory case of git --progress whatever --no-progress (or\nviceversa) was going to be my follow-up question. Dude, don't get too\nfar ahead in the conversation :-)\n\nOn the technical side, I think the global --progress option (and\nremoving the option from the builtins) would not add complexity but\nthe opposite because setting the flag would be done at the \"main git\"\nlevel and then all the builtins would just forget about it and would\nuse progress regardless (cause deciding _if_ progress should be shown\nor not won't be up to them anymore) so the code from the builtins to\nsupport the option would be gone. It would certainly be more complex\nwhile keeping global and builtin options alive. Anyway, I do\nunderstand your concerns and will stand down on the topic (as in....\nglobal --progress who???).\n\n> A lot more useful thing to do in the same area with a lot smaller\n> amount of effort would be to find an operation that sometimes take a\n> long time to perform that does not show the progress report and\n> teach the codepath involved in the operation to show progress, I\n> would think.\n\nSounds interesting and in-topic (different direction). You got a list\nof those paths that I could work on? At least a couple you can think\noff the top of your head? Cause I can't complain about the progress I\nget on the workflows I follow (although I could keep a closer look to\ntry to catch some operation I know is taking place and is not showing\nany progress and I'm used to it and so I don't complain at the lack of\nprogress). Right now I'm thinking about cherry-picking... sometimes it\ncan take a few seconds (or more seconds.... you have to see the\nperformance of some of the boxes that I work on) and getting some\nprogress there would be nice. Will take a look at it. Nice way to get\nfamiliarized with the code, by the way.\n\nThank you very much, Junio!\n"},{"id":"272947","messageId":"20151105070841.GC4725@sigill.intra.peff.net","threadId":"40725","inReplyTo":"CAOc6etbuK7=-8kH60taO8uH+6XNGTFRNGmmkswgP-19bCRNB3Q@mail.gmail.com","subject":"Re: About global --progress option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-11-05T07:08:41Z","receivedAt":"2015-11-05T07:08:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 05, 2015 at 12:47:22AM -0600, Edmundo Carmona Antoranz wrote:\n\n> On the technical side, I think the global --progress option (and\n> removing the option from the builtins) would not add complexity but\n> the opposite because setting the flag would be done at the \"main git\"\n> level and then all the builtins would just forget about it and would\n> use progress regardless (cause deciding _if_ progress should be shown\n> or not won't be up to them anymore) so the code from the builtins to\n> support the option would be gone. It would certainly be more complex\n> while keeping global and builtin options alive. Anyway, I do\n> understand your concerns and will stand down on the topic (as in....\n> global --progress who???).\n\nI think you are missing one important element, which is that git\nprograms do not all share a memory space with the main git binary. So\nyou cannot simply set the \"progress\" variable in the main program and\nexpect everybody to see it. Running \"git foo\" may invoke a separate\n\"git-foo\" program, written in another language entirely.\n\nFor that reason, options to the main git binary typically set an\nenvironment variable which is communicated to all sub-processes. For an\nexample, see how \"--literal-pathspecs\" is implemented. So it actually\ndoes add some complexity.\n\nThat being said, the environment variable can be a good thing. For\nexample, imagine I have a script \"git-foo\" which runs several commands,\nincluding \"git-fetch\". It's cumbersome for \"git-foo\" to take a\n\"--progress\" option and then pass that down to \"git-fetch\". If you could\ninstead run:\n\n  git --no-progress foo\n\nand have that flag magically propagate to any git sub-programs which\ncare about showing progress, then that could perhaps make the feature\nworthwhile (I say perhaps because while it seems plausible to me, I have\nnot heard of anyone actually wanting this feature in practice).\n\nBut adding in \"git --progress\" is an orthogonal decision to removing\nsupport for \"git <cmd> --progress\". I do not see any big advantage to\nthe latter at this point, and a lot of potential negatives as we break\nscripts and user expectations.\n\n-Peff\n"}]}