[PATCH 0/2] handling REF_STATUS_EXPECTING_REPORT over http

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