path: root/sub-process.c
diff options
authorJunio C Hamano <>2017-09-11 03:21:29 (GMT)
committerJunio C Hamano <>2017-09-11 03:21:29 (GMT)
commitab46e6fc7265de3e354d7eaaa7ed7c1e2426171f (patch)
tree1c91cba463bc5f1ecb1471d5a858572604459ce3 /sub-process.c
parentd3ba566342a4fd81b24d926efc35506d58e10a19 (diff)
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 <>
Diffstat (limited to 'sub-process.c')
1 files changed, 2 insertions, 2 deletions
diff --git a/sub-process.c b/sub-process.c
index fcc4832..ec9a51b 100644
--- a/sub-process.c
+++ b/sub-process.c
@@ -181,8 +181,8 @@ static int handshake_capabilities(struct child_process *process,
if (supported_capabilities)
*supported_capabilities |= capabilities[i].flag;
} else {
- warning("subprocess '%s' requested unsupported capability '%s'",
- process->argv[0], p);
+ die("subprocess '%s' requested unsupported capability '%s'",
+ process->argv[0], p);