summaryrefslogtreecommitdiff
path: root/t/t5507-remote-environment.sh
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2017-09-11 12:21:29 +0900
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-09-11 12:21:29 +0900
commitab46e6fc7265de3e354d7eaaa7ed7c1e2426171f (patch)
tree1c91cba463bc5f1ecb1471d5a858572604459ce3 /t/t5507-remote-environment.sh
parentsub-process: print the cmd when a capability is unsupported (diff)
downloadtgif-ab46e6fc7265de3e354d7eaaa7ed7c1e2426171f.tar.xz
subprocess: loudly die when subprocess asks for an unsupported capability
The handshake_capabilities() function first advertises the set of capabilities it supports, so that the other side can pick and choose which ones to use and ask us to enable in its response. Then we read the response that tells us what choice the other side made. If we saw something that we never advertised, that indicates one of two things. The other side, i.e. the "upgraded" filter, is not paying attention of the capabilities advertisement, and asking something its correct operation relies on, but we are not capable of giving that unknown feature and operate without it, so after that point the exchange of data is a garbage-in-garbage-out. Or the other side wanted to ask for one of the capabilities we advertised, but the code has typo and their wish to enable a capability that its correct operation relies on is not understood on this end. The result is the same garbage-in-garbage-out. Instead of sweeping such a potential bug under the rug, die loudly when we see a request for an unsupported capability in order to force sloppily-written filter scripts to get corrected. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5507-remote-environment.sh')
0 files changed, 0 insertions, 0 deletions