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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html