About global --progress option

About global --progress option

[Edmundo Carmona Antoranz]

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.

Re: About global --progress option

[Junio C Hamano]

Edmundo Carmona Antoranz <eantoranz@gmail.com> 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.

Re: About global --progress option

[Edmundo Carmona Antoranz]

On Thu, Nov 5, 2015 at 12:11 AM, Junio C Hamano <gitster@pobox.com> 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!

Re: About global --progress option

[Jeff King]

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