Re: [PATCH 3/3] rev-parse: handle --end-of-options

From: Jeff King <peff@peff.net>
Date: Nov 11, 2020, 02:22 UTC
Message-ID: <20201111022238.GA806755@coredump.intra.peff.net>
In-Reply-To: <xmqqr1p06ec9.fsf@gitster.c.googlers.com>

On Tue, Nov 10, 2020 at 02:23:34PM -0800, Junio C Hamano wrote:

Show 17 quoted lines

> Jeff King <peff@peff.net> 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. ;)

Show 8 quoted lines

> > +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