summaryrefslogtreecommitdiff
path: root/ls-refs.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2021-09-15 18:36:38 (GMT)
committerJunio C Hamano <gitster@pobox.com>2021-09-15 19:25:19 (GMT)
commitccf094788c50c597972ee1fd9c2b554cadc0f14c (patch)
tree53e1be40071746184f9578510771a3f53e9ffd24 /ls-refs.c
parent0ab7eeccd9aea668819288c086dcdf57ca14a026 (diff)
downloadgit-ccf094788c50c597972ee1fd9c2b554cadc0f14c.zip
git-ccf094788c50c597972ee1fd9c2b554cadc0f14c.tar.gz
git-ccf094788c50c597972ee1fd9c2b554cadc0f14c.tar.bz2
ls-refs: reject unknown arguments
The v2 ls-refs command may receive extra arguments from the client, one per pkt-line. The spec is pretty clear that the arguments must come from a specified set, but we silently ignore any unknown entries. For a well-behaved client this doesn't matter, but it makes testing and debugging more confusing. Let's tighten this up to match the spec. In theory this liberal behavior _could_ be useful for extending the protocol. But: - every other part of the protocol requires that the server first indicate that it supports the argument; this includes the fetch and object-info commands, plus the "unborn" capability added to ls-refs itself - it's not a very good extension mechanism anyway; without the server advertising support, clients would have no idea if the argument was silently ignored, or accepted and simply had no effect So we're not really losing anything by tightening this. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'ls-refs.c')
-rw-r--r--ls-refs.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/ls-refs.c b/ls-refs.c
index 07429f3..883c0c5 100644
--- a/ls-refs.c
+++ b/ls-refs.c
@@ -170,6 +170,8 @@ int ls_refs(struct repository *r, struct packet_reader *request)
}
else if (!strcmp("unborn", arg))
data.unborn = allow_unborn;
+ else
+ die(_("unexpected line: '%s'"), arg);
}
if (request->status != PACKET_READ_FLUSH)