Re: Bug: version 2.4 seems to have broken `git clone --progress`

On Mon, May 11, 2015 at 02:06:15PM -0700, Junio C Hamano wrote:

"Jack O'Connor" [off-list ref] writes:

quoted

In git 2.3.7 I could run the following command and see progress in the
terminal, despite the redirection of stdout and stderr:

    git clone https://github.com/oconnor663/dotfiles --progress 2>&1 | cat

As of 2.4, that command no longer shows progress. When I bisect, the
responsible commit is 2879bc3b0c3acc89f0415ac0d0e3946599d9fc88
("transport-helper: ask the helper to set progress and verbosity
options after asking for its capabilities"). Can anyone suggest a
workaround?

-- Jack O'Connor

That commit is by Mike Hommey [off-list ref] so I'd imagine that
CC'ing the author of the patch would be the first thing to do ;-)

I am kind of surprised that the commit changes behaviour, though.
If I didn't hear that you had trouble in 2.4, I would have suspected
85cb8906 (progress: no progress in background, 2015-04-13) instead.

So, the reason this is happening is that 2879bc3 moved sending the
progress helper option earlier, and for clone, it's early enough that
transport_set_verbosity happens afterwards. Since
transport_set_verbosity only sets the progress bit, and nothing re-emits
a helper option command when it changes, we're left with the default,
which is that no progress is shown if the output file descripto is not
a tty.

I can see two ways to fix this:
- Make transport_set_verbosity call transport->set_option instead of
  defering to standard_options() in transport-helper.c.
- Declare that transport_set_verbosity must be used before any other
  transport_set_option, and change clone to invoke it first. Note that
  fetch and push already do that, so this is only currently a problem
  for clone.

Junio, what do you think?

Mike