summaryrefslogtreecommitdiff
path: root/t/.gitattributes
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2021-10-18 15:45:56 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-10-18 13:27:36 -0700
commitc5c3486f38af50e3d63b3bd1d1d25773e4f4420a (patch)
treee42101da38232b8d8cd234d5955848613a1915c0 /t/.gitattributes
parentsend-pack: complain about "expecting report" with --helper-status (diff)
downloadtgif-c5c3486f38af50e3d63b3bd1d1d25773e4f4420a.tar.xz
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>
Diffstat (limited to 't/.gitattributes')
0 files changed, 0 insertions, 0 deletions