| Issue 2951: | Gerrit doesn't honor git push --no-progress | |
| 4 people starred this issue and may be notified of changes. | Back to list |
Affected Version: 2.8.6.1 What steps will reproduce the problem? 1. Trying to push with command like: $ git push --no-progress ssh://me@review.some.org:29418/people/paul.sokolovsky/test.git HEAD:delme1 I get following output: remote: Resolving deltas: 100% (14781/14781) remote: Processing changes: refs: 1, done To ssh://me@review.some.org:29418/people/paul.sokolovsky/test.git * [new branch] HEAD -> delme1 Note two lines starting with "remote:" - I asked my local git to not provide upload progress updates. My local git passed that into to remote upload-pack (or whatever), but it ignored that request and still output it. If I redirect that to a log file, my log files will contain a lot of junk lines like "Resolving deltas: 1%<CR>", repeated, which makes reviewing logs quite complicated. Note that I know about "git push -q" - that's not what I want, I still want to see what new refs were pushed, I just don't won't to see unneeded progress indicator junk in log files. What is the expected output? What do you see instead? For comparison, pushing using the standard git SSH access: $ git push --no-progress git.some.org:people/paul.sokolovsky/test.git HEAD:delme1 To git.some.org:people/paul.sokolovsky/test.git * [new branch] HEAD -> delme1 As can be seen, no upload progress updates are output.
Oct 31, 2014
#1
richard.moehn@googlemail.com
Oct 31, 2014
There is probably a JGit bug in here but I think it's arguably also a bug in the git client. The documentation for the no-progress capability says: no-progress ----------- The client was started with "git clone -q" or something, and doesn't want that side band 2. Basically the client just says "I do not wish to receive stream 2 on sideband, so do not send it to me, and if you did, I will drop it on the floor anyway". However, the sideband channel 3 is still used for error responses. The git client is not in fact dropping it on the floor as that documentation implies it would.
Nov 24, 2014
Either Git is confused, or I am confused, or both. There are three protocol capabilities: * no-progress (upload-pack only) * quiet (upload-pack and receive-pack) * report-status (receive-pack) There are three protocol bands: * data * progress messages * errors (Non-data protocol bands are collectively referred to as "sideband.") There are two flags to fetch/push: * --progress * --quiet I will describe some highlights of the relationships between them as I understand them, but I am by no means deeply familiar with these parts of the C git code, nor am I going to list all permutations here. Once we know what git expects to happen, it's a "simple" matter of making sure JGit does the same thing in all cases, though I haven't made an inventory of what it currently does correctly/incorrectly. * --no-progress is accepted as a flag to both fetch and push, but I think it's just ignored by the push code since no-progress is not a receive-pack capability. * The correct behavior for fetch is to connect the error band from the remote to stderr. * Pretty sure --quiet is intended to suppress _all_ sideband output, including errors. * I _think_ the no-progress capability suppresses all messages from the progress band only, and leaves the error band alone. * report-status tells the server to send a final status report over the progress band. But the client doesn't distinguish between progress messages and the final status report; it doesn't do any parsing of the results. So from the client's perspective they are indistinguishable, it trusts the server to make the distinction. * Gerrit uses the progress band for all of the multi progress monitor, normal receive-pack progress monitors, validation warnings/errors, and the final status report. So, insofar as Gerrit does not respect the quiet capability on push, it should. Insofar as Gerrit does not respect the --no-progress flag when passed to push, that's Git's fault: that flag does nothing.
Nov 24, 2014
Mistake from the previous message: * --quiet is a flag to both fetch and push but only a protocol capability only for receive-pack (push). AFAICT `git push --no-progress` really does nothing on the wire: $ GIT_TRACE_PACKET=1 git push origin refs/remotes/origin/master:refs/for/master 15:23:03.393986 pkt-line.c:46 packet: git< # service=git-receive-pack 15:23:03.394035 pkt-line.c:46 packet: git< 0000 15:23:03.394051 pkt-line.c:46 packet: git< 6f083b89426fffd0d51f03ededc5b5c2e73c2487 refs/heads/master\0 side-band-64k delete-refs report-status ofs-delta ... 15:23:03.463709 pkt-line.c:46 packet: git> 0000000000000000000000000000000000000000 6f083b89426fffd0d51f03ededc5b5c2e73c2487 refs/for/master\0 report-status side-band-64k 15:23:03.463736 pkt-line.c:46 packet: git> 0000 15:23:03.463797 pkt-line.c:46 packet: git< 00820000000000000000000000000000000000000000 6f083b89426fffd0d51f03ededc5b5c2e73c2487 refs/for/master\0 report-status side-band-64k0000 Total 0 (delta 0), reused 0 (delta 0) 15:23:04.002911 pkt-line.c:46 packet: git> 0000 15:23:05.849286 pkt-line.c:46 packet: git< \2\15Processing changes: refs: 1 remote: Processing changes: refs: 115:23:05.849392 pkt-line.c:46 packet: git< \2\15Processing changes: refs: 1, done remote: Processing changes: refs: 1, done 15:23:05.849422 pkt-line.c:46 packet: git< \1000eunpack ok0026ng refs/for/master no new changes0000 15:23:05.849444 pkt-line.c:46 packet: git< 0000 15:23:05.849480 pkt-line.c:46 packet: git< unpack ok 15:23:05.849513 pkt-line.c:46 packet: git< ng refs/for/master no new changes ... $ GIT_TRACE_PACKET=1 git push --no-progress origin refs/remotes/origin/master:refs/for/master 15:23:13.531238 pkt-line.c:46 packet: git< # service=git-receive-pack 15:23:13.531288 pkt-line.c:46 packet: git< 0000 15:23:13.531303 pkt-line.c:46 packet: git< 6f083b89426fffd0d51f03ededc5b5c2e73c2487 refs/heads/master\0 side-band-64k delete-refs report-status ofs-delta ... 15:23:13.606520 pkt-line.c:46 packet: git> 0000000000000000000000000000000000000000 6f083b89426fffd0d51f03ededc5b5c2e73c2487 refs/for/master\0 report-status side-band-64k 15:23:13.606544 pkt-line.c:46 packet: git> 0000 15:23:13.606640 pkt-line.c:46 packet: git< 00820000000000000000000000000000000000000000 6f083b89426fffd0d51f03ededc5b5c2e73c2487 refs/for/master\0 report-status side-band-64k0000 15:23:13.739301 pkt-line.c:46 packet: git> 0000 15:23:14.961802 pkt-line.c:46 packet: git< \2\15Processing changes: refs: 1 remote: Processing changes: refs: 115:23:14.961890 pkt-line.c:46 packet: git< \2\15Processing changes: refs: 1, done remote: Processing changes: refs: 1, done 15:23:14.961918 pkt-line.c:46 packet: git< \1000eunpack ok0026ng refs/for/master no new changes0000 15:23:14.961962 pkt-line.c:46 packet: git< 0000 15:23:14.961989 pkt-line.c:46 packet: git< unpack ok 15:23:14.962024 pkt-line.c:46 packet: git< ng refs/for/master no new changes Both client (git>) and server (git<) capabilities lines are identical. However, JGit does not advertise the "quiet" capability on receive-pack at all. Maybe --no-progress will cause it to send "quiet" if the server advertises it? It is definitely a missing feature in JGit to support the "quiet" capability.
Nov 24, 2014
We use -quiet for push. It would be awesome if JGit would suppress the progress output when the quiet capability is set.
Nov 24, 2014
One thing I haven't verified is whether a C git server suppresses the final status report with --quiet. |
|
| ► Sign in to add a comment |