Re: Push not writing to standard error

[Jeff King <peff@peff.net>]

On Wed, Oct 13, 2010 at 10:33:22AM -0700, Junio C Hamano wrote:

> > Here's a quick 5-minute patch. It works on my test case:
> >
> >   rm -rf parent child
> >   git init parent &&
> >   git clone parent child &&
> >   cd child &&
> >   echo content >file && git add file && git commit -m one &&
> >   git push --progress origin master:foo >foo.out 2>&1 &&
> >   cat foo.out
> 
> Does it still work with "git push" without --progress?  I didn't apply nor
> test, but just wondering as the manpage description suggests progress is
> implicitly set when standard error is terminal even when there is no
> command line --progress is given, and also interaction with -q option, but
> the patch does not seem to show such subtleties...

Yes, it works in both of those cases. The transport code already does
the right thing to set transport->progress (see the code at the end of
transport_set_verbosity). And we even pass that value on to remote
helpers, which presumably make use of it. But the internal
git_transport_push simply ignored it (probably because it predates the
rest of the transport code, but I didn't check).

What concerns me a bit is that "git push --no-progress" does not do what
I expected (turn off progress, but keep the status table which would
otherwise be suppressed by "-q"). Instead, --no-progress is silently
ignored. We should at least set it to NONEG to generate an error, but
ideally we would handle it properly.

However, that bug exists with or without my patch. The transport code
seems to only ever consider "force progress" or "default progress", but
never "no progress".

-Peff