diff options
author | Junio C Hamano <gitster@pobox.com> | 2017-09-11 12:21:29 +0900 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-09-11 12:21:29 +0900 |
commit | ab46e6fc7265de3e354d7eaaa7ed7c1e2426171f (patch) | |
tree | 1c91cba463bc5f1ecb1471d5a858572604459ce3 /t/t7610-mergetool.sh | |
parent | sub-process: print the cmd when a capability is unsupported (diff) | |
download | tgif-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/t7610-mergetool.sh')
0 files changed, 0 insertions, 0 deletions