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

[Mike Hommey <mh@glandium.org>]

On Mon, May 11, 2015 at 07:04:20PM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > 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?
> 
> The latter sounds like more appropriate as a lower-impact short-term
> fix, so let's have that for now.
> 
> I however wonder if there are other settings that can be flipped
> after we started talking to the helper to cause a similar issue,
> and to prevent such breakages once and for all, we may have to
> take the former route in the longer term.  But I think that can be
> done later after the dust settles.

AFAICT, verbosity/progress is the only thing that is really treated
differently. transport_set_options always sends options to the remote
helper wire.

Mike