]> git.ipfire.org Git - thirdparty/git.git/commit
transport-helper: recognize "expecting report" error from send-pack
authorJeff King <peff@peff.net>
Mon, 18 Oct 2021 19:45:56 +0000 (15:45 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 18 Oct 2021 20:27:36 +0000 (13:27 -0700)
commitc5c3486f38af50e3d63b3bd1d1d25773e4f4420a
treee42101da38232b8d8cd234d5955848613a1915c0
parente4c9538a9cdc816b3392553edcddf6692af7c0a9
transport-helper: recognize "expecting report" error from send-pack

When a transport helper pushes via send-pack, it passes --helper-status
to get a machine-readable status back for each ref. The previous commit
taught the send-pack code to hand back "error expecting report" if the
server did not send us the proper ref-status. And that's enough to cause
us to recognize that an error occurred for the ref and print something
sensible in our final status table.

But we do interpret these messages on the remote-helper side to turn
them back into REF_STATUS_* enum values.  Recognizing this token to turn
it back into REF_STATUS_EXPECTING_REPORT has two advantages:

  1. We now print exactly the same message in the human-readable (and
     machine-readable --porcelain) output for this situation whether the
     transport went through a helper (e.g., http) or not (e.g., ssh).

  2. If any code in the helper really cares about distinguishing
     EXPECT_REPORT from more generic error conditions, it could now do
     so. I didn't find any, so this is mostly future-proofing.

So this is mostly cosmetic for now, but it seems like the
least-surprising thing for the transport-helper code to be doing.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5541-http-push-smart.sh
transport-helper.c