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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 27.11.2023 um 22:22 schrieb Jeff King:
$ 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





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux