On Tue, Nov 10, 2020 at 02:23:34PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > This patch lets callers write: > > > > git rev-parse --end-of-options "$rev" -- "$path" > > > > and: > > > > git rev-parse --verify --end-of-options "$rev" > > > > which will both treat "$rev" always as a revision parameter. > > Nice. The only iffy case I can think of is that we can never have > "--" to specify a rev, because with "git cmd -- -- path" we don't > know which double-dash among the two is the disambiguator that makes > the other double-dash to be either rev or path, but that is not a > new problem with this change. Yeah. It is sufficient to me that "rev-parse" (or any command) does not do a bad thing when somebody malicious asks about "--", even if the repo contents themselves are sane and do not have "--". If somebody has a not-sane repo with refs/heads/-- and the worst case is that they have trouble accessing it without a fully-qualified name, then I find it hard to sympathize. ;) > > +test_expect_success 'verify respects --end-of-options' ' > > + git update-ref refs/heads/-tricky HEAD && > > + git rev-parse --verify HEAD >expect && > > + git rev-parse --verify --end-of-options -tricky >actual && > > + test_cmp expect actual > > +' > > ;-) Or refs/heads/--tricky? Yeah, arguably that is a better name. It could even be a real option name, though once the bug is fixed none of it matters. :) -Peff
