On Tue, May 01, 2012 at 02:58:32AM -0400, Jeff King wrote:
> > I just updated to msysGit 1.7.10 and I noticed I don't see any details
> > while pushing (like file upload speed and % completion). Was this
> > intentionally removed? If so why?
>
> No, it's a regression. I can reproduce it easily, and it bisects to
> Clemens' 01fdc21 (push/fetch/clone --no-progress suppresses progress
> output) which went into v1.7.9.2 (and v1.7.10).
Hmm. OK, I think I see what is going on. For most protocols, send_pack
happens without a separate process these days. So the stack is like:
- transport_push
- git_transport_push
- send_pack
where the "progress" flag to send_pack is a boolean; we have already
figured out at the transport layer whether we want progress, and are
telling it what to do. Thus this hunk from 01fdc21 makes sense:
> diff --git a/builtin/send-pack.c b/builtin/send-pack.c
> index 71f258e..9df341c 100644
> --- a/builtin/send-pack.c
> +++ b/builtin/send-pack.c
> @@ -58,7 +58,7 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
> argv[i++] = "--thin";
> if (args->use_ofs_delta)
> argv[i++] = "--delta-base-offset";
> - if (args->quiet)
> + if (args->quiet || !args->progress)
> argv[i++] = "-q";
> if (args->progress)
> argv[i++] = "--progress";
If we have been asked not to have progress, then we tell pack-objects
"-q" (which is, for historical reasons, the way to spell "--no-progress"
for pack-objects).
But send-pack is also a command in its own right, and gets invoked
separately for the --stateless-rpc case (i.e., smart http). In that case
you end up with:
- transport_push
- transport-helper.c:push_refs
- [pipes to git-remote-https]
- remote-curl.c:push_git
- [forks send-pack]
- cmd_send_pack
- send_pack
In this case, send pack gets its arguments from the command-line, not
from the options set at the transport layer. Remote-curl will pass along
"--quiet" if we get that from the transport layer, but it does not
otherwise pass along the "progress" flag. So there are two problems:
1. send-pack defaults its progress boolean to 0. Before 01fdc21, that
was OK, because it meant "don't explicitly ask for progress". But
after 01fdc21 that now means "explicitly ask for no progress", and
the direct-transport code paths were updated without updating
cmd_send_pack.
2. There's no way to tell send-pack explicitly "yes, I would like
progress, no matter what isatty(2) says". I doubt anybody cares
much, but it probably makes sense to handle that for the sake of
completeness.
-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