The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,969 other subscribers

git the meaning of `–` is to treat the rest of the arguments as file names (Hard reset of a single file – Stack Overflow)

Posted by jpluimers on 2020/12/16

Learned TWO things at once Mark Longair and VonC at [WayBack] git – Hard reset of a single file – Stack Overflow :

You can use the following command:

git checkout HEAD -- my-file.txt

… which will update both the working copy of my-file.txt and its state in the index with that from HEAD.

-- basically means: treat every argument after this point as a file name. More details in this answer. Thanks to VonC for pointing this out.


  • [WayBack] User Mark Longair – Stack Overflow
  • [WayBack] User VonC – Stack Overflow
  • [WayBack] User zwol – Stack Overflow
  • [WayBack] Difference between “git checkout ” and “git checkout -​- ” – Stack Overflow

    The special “option” -- means “treat every argument after this point as a file name, no matter what it looks like.” This is not Git-specific, it’s a general Unix command line convention. Normally you use it to clarify that an argument is a file name rather than an option, e.g.

    rm -f      # does nothing
    rm -- -f   # deletes a file named "-f"

    git checkout1 also takes -- to mean that subsequent arguments are not its optional “treeish” parameter specifying which commit you want.

    So in this context it’s safe to use -- always, but you need it when the file you want to revert has a name that begins with -, or is the same as the name of a branch. Some examples for branch/file disambiguation:

    git checkout README     # would normally discard uncommitted changes
                            # to the _file_ "README"
    git checkout master     # would normally switch the working copy to
                            # the _branch_ "master"
    git checkout -- master  # discard uncommitted changes to the _file_ "master"

    and option/file disambiguation:

    git checkout -p -- README  # interactively discard uncommitted changes
                               # to the file "README"
    git checkout -- -p README  # unconditionally discard all uncommitted
                               # changes to the files "-p" and "README"

    I’m not sure what you do if you have a branch whose name begins with -. Perhaps don’t do that in the first place.

    1 in this mode; “checkout” can do several other things as well. I have never understood why git chose to implement “discard uncommitted changes” as a mode of the “checkout” subcommand, rather than “revert” like most other VCSes, or “reset” which I think might make more sense in git’s own terms.

  • [WayBack] Deleting a badly named git branch – Stack Overflow

    Did you try

    git branch -D -- --track

    ? the “--” is usually the convention for “what follows is not an option, whatever its name”

    From “The Art of Unix Programming“, section “Command-Line Options“:

    It is also conventional to recognize a double hyphen as a signal to stop option interpretation and treat all following arguments literally.

    You will find that convention in other (not necessary Unix-related) CLI (Command Line Interface) like cleartool:

    If a nonoption argument begins with a hyphen () character, you may need to precede it with a double-hyphen argument, to prevent it from being interpreted as an option:

    cleartool rmtype -lbtype -- -temporary_label- 

    The P18 (a fast and flexible file preprocessor with macro processing capabilities and special support for internationalization) mentions that also and gives a good description of the general idea behind that convention:

    All option arguments passed to the commands start with a single hyphen.
    All option arguments (if any) must precede all non-option arguments.
    The end of the option arguments may be signaled using a double hyphen, this is useful if a non-option argument starts with a hyphen. Terminating the list of option arguments with a double hyphen works for all commands, even those that don’t take any option arguments.

    The OptionParser tool written in ruby also lays it out quite plainly:*

    Option Parsing Termination

    It is convention that a double hyphen is a signal to stop option interpretation and to read the remaining statements on the command line literally. So, a command such as:

     app -- -x -y -z

    will not ‘see’ the three mode-flags. Instead, they will be treated as arguments to the application:

     #args = ["-x", "-y", "-z"]

    Note: sometimes, it takes three dashes and not two, especially when the CLI follows strictly the Gnu options styles:

    The Gnu style command line options provide support for option words (or keywords), yet still maintain compatibility with the Unix style options.
    The options in this style are sometimes referred to as long_options and the Unix style options as short_options.
    The compatibility is maintained by preceding the long_options with two dashes

    Similar to the Unix style double-hyphen ’--’, the Gnu style has a triple-hyphen ’---’ to signal that option parsing be halted and to treat the remaining text as arguments (that is, read literally from the command line)

    So… if ‘ -- ‘ is not enough (it should be with Git commands), try ‘ --- ‘


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: