@matheusbsbs / matheus-bagliano / commits / ccf094788c

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>

Jeff King committed Sep 15, 2021 at 14:36 UTC ccf094788c50c597972ee1fd9c2b554cadc0f14c
2 files changed +15
ls-refs.c
+2
@@ -170,6 +170,8 @@ int ls_refs(struct repository *r, struct packet_reader *request)
170 }
171 else if (!strcmp("unborn", arg))
172 data.unborn = allow_unborn;
173 + else
174 + die(_("unexpected line: '%s'"), arg);
175 }
176
177 if (request->status != PACKET_READ_FLUSH)
t/t5701-git-serve.sh
+13
@@ -147,6 +147,19 @@ test_expect_success 'basics of ls-refs' '
147 test_cmp expect actual
148 '
149
150 +test_expect_success 'ls-refs complains about unknown options' '
151 + test-tool pkt-line pack >in <<-EOF &&
152 + command=ls-refs
153 + object-format=$(test_oid algo)
154 + 0001
155 + no-such-arg
156 + 0000
157 + EOF
158 +
159 + test_must_fail test-tool serve-v2 --stateless-rpc 2>err <in &&
160 + grep unexpected.line.*no-such-arg err
161 +'
162 +
163 test_expect_success 'basic ref-prefixes' '
164 test-tool pkt-line pack >in <<-EOF &&
165 command=ls-refs