Re: --end-of-options inconsistently available?!

From: Sven Strickroth <sven@cs-ware.de>
Date: Nov 28, 2023, 08:40 UTC
Message-ID: <ab14260c-d515-425e-8ef6-5739d3d6ca4e@cs-ware.de>
In-Reply-To: <20231127212254.GA87495@coredump.intra.peff.net>

Am 27.11.2023 um 22:22 schrieb Jeff King:

Show 23 quoted lines

>> $ git rev-parse --symbolic-full-name --end-of-options master
>> --end-of-options
>> refs/heads/master
>>
>> Here, the output also contains "--end-of-options" as if it is a reference
>> (same for "--")
> 
> This one is intentional. rev-parse in its default mode is not just
> spitting out revisions, but also options that are meant to be passed
> along to the revision machinery via other commands (like rev-list). So
> for example:
> 
>    $ git rev-parse --foo HEAD
>    --foo
>    564d0252ca632e0264ed670534a51d18a689ef5d
> 
> And it does understand end-of-options explicitly, so:
> 
>    $ git rev-parse --end-of-options --foo --
>    --end-of-options
>    fatal: bad revision '--foo'
> 
> If you just want to parse a name robustly, use --verify.

I would expect that -- and --end-of-options are handled in a special way here so that rev-parse can also be used in scripts. I need to check whether --verify works for me (from the manual I thought I need to specify full reference names).

>> $ git checkout -f --end-of-options HEAD~1 -- afile.txt
>> fatal: only one reference expected, 2 given.
> 
> I think this is the same KEEP_DASHDASH problem as with git-reset.

I also found another problem: $ git format-patch --end-of-options -1 fatal: option '-1' must come before non-option arguments

Where -1 is the number of commits here...

Best,
  Sven