Re: [PATCH] revision: allow pseudo options after --end-of-options

From: Jeff King <peff@peff.net>
Date: Jul 12, 2021, 19:47 UTC
Message-ID: <YOycOlyqwwWZJ6rH@coredump.intra.peff.net>
In-Reply-To: <xmqqim1f5pz8.fsf@gitster.g>

On Mon, Jul 12, 2021 at 11:47:23AM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I don't think fully-qualifying refs is a complete solution, though. The
> > common use case for --end-of-options is that you're passing along names
> > from somewhere else, and you don't know how to qualify them. E.g., in:
> >
> >   git rev-list --end-of-options "$rev" --
> >
> > you need to behave differently if you got "1234abcd" versus "foo" versus
> > "refs/heads/foo".
> 
> I suspect that you can prefix "^^" unconditionally, just like --not
> can be emulated away by unconditionally prefixing "^".

That would be clever, but I think we only parse a single "^":

  $ git rev-list ^HEAD
  [no output]
  $ git rev-list ^^HEAD
  fatal: bad revision '^^HEAD'

  $ git rev-parse ^HEAD
  ^d486ca60a51c9cb1fe068803c3f540724e95e83a
  $ git rev-parse ^^HEAD
  ^^HEAD
  fatal: ambiguous argument '^^HEAD': unknown revision or path not in the working tree.

-Peff