I recently saw a case where GitHub's server implementation failed to
correctly report ref statuses. In this case it was because it hit an
internal timeout, but the root cause doesn't really matter; the server
is doing the wrong thing.
But what's interesting on the Git client side is that we produce quite a
confusing message for http. For ssh, we correctly say something like (in
this example, I'm pushing an absurd number of tags that causes the
timeout):
To ssh://github.com/some/repo
! [remote failure] tag-1 -> tag-1 (remote failed to report status)
[...etc...]
! [remote failure] tag-999 -> tag-999 (remote failed to report status)
error: failed to push some refs to 'ssh://github.com/some/repo'
but for http, I get just:
Everything up-to-date
Which is misleading to say the least. The issue is communication between
send-pack and remote-curl on the client side.
The first patch does the minimal fix. The second one has some cosmetic
improvements. They arguably could be squashed together, but I think
keeping them split shows exactly what the second patch is actually
accomplishing (especially with the minor change to the expected output
in the test).
This bug has been around since smart http was added in 2009. I just
prepared it on master, but I expect it could also go to maint.
[1/2]: send-pack: complain about "expecting report" with --helper-status
[2/2]: transport-helper: recognize "expecting report" error from send-pack
builtin/send-pack.c | 4 ++++
t/lib-httpd.sh | 1 +
t/lib-httpd/apache.conf | 4 ++++
t/lib-httpd/error-no-report.sh | 6 ++++++
t/t5541-http-push-smart.sh | 16 ++++++++++++++++
transport-helper.c | 4 ++++
6 files changed, 35 insertions(+)
create mode 100644 t/lib-httpd/error-no-report.sh
-Peff
