git's –end-of-options Flag

Join the discussion

• Hacker News
• When I read Claude lingo [1] in a nominally human-authored piece it gives a sensation akin to cockroaches crawling on your face.

  Which seems unfair because what if they have subconsciously regurgitated Claude-speak?

  [1] "That’s a real cost,"

  by angry_octet
• https://m.xkcd.com/1597/

  By the way, something munched the article title. An endash is incorrect command-line usage. It’s supposed to be a double hyphen.

  by ButlerianJihad
• I'm sure I typed double-hyphen when submitting the post, but probably HN auto-formatted the title. IDK really.
  by ErenayDev
• From the title I've learned that git uses an em-dash instead of double dash as options delimiter. Thanks for pointing out that the title was wrong -- I've never had a need to use -- with git, so didn't know that it doesn't work.
  by wafflemaker
• It is an en dash, not an em dash, since it's about as wide as an n.

  Some software substitutes a double hyphen -- with an en dash rather than em, and use the triple hyphen --- for the em dash. Perhaps Hacker News' title formatter is one of them.

  by sheept
• Perhaps I'm missing something (it's been a long day), but couldn't "--" be used for both?

      git cmd --options -- rev -- pathspec
  

  would be the fully specified revspec and pathspec

      git cmd --option -- rev --
  

  would be just the revspec, excluding accidental options, without a pathspec

      git cmd --option revspec -- pathspec
  

  and the single "--" would work as it currently does.
  by epistasis
• If it's used for both, then you couldn't have "--" itself as a pathspec. In your first example, the current meaning is: a pathspec containing "rev", "--", and "pathspec".
  by peff
• Currently, git log -- a -- prints all commits that affects the files whose name is a or two dashes.
  by gene91
• This is actually one of the few places powershell begins to do something close to shine - the cli mixes data and commands in a way that we really shouldn't have to do.

  The saddest thing is even ASCII has characters to help with this but since keyboards can't type them nobody used them.

  by bombcar
• If keyboards did have keys for ASCII delimiters, people would start using them for a variety of purposes, and they'd start showing up in data streams, leading to the same issues we face with the typable delimiter characters we currently use. It's sort of a catch-22.
  by Gormo
• > git log --end-of-options "$rev" -- "$path",

  Argh, that's when I wished for object oriented shells. Powershell sure isn't perfect but objects encoding their own meaning really helps differentiate those cases (but it may not always help the user if types aren't clear to the reader)

  by _blk
• I don't think you need object orientation for that. Haskell and Rust solve these problems also just fine, without any OOP in sight.
  by eru
• The "Everything is text, do everything via text" philosophy has its advantages, and also its disadvantages.
  by Chinjut
• What are the advantages over structured text?
  by eviks
• Like the von Neumann architecture. Your data can be misused as code.

  Don't see that we get rid of either command lines in text or von Neumann any time soon.

  by usr1106
• As with almost any successful system: more and more special features and edge cases get added. Git has become ridiculously complex.

  I wonder: would it not be better to tell users with those edge cases to fix their problems some other way? To take an example from the article: why does someone have a filename beginning with a dash? Maybe don't do that.

  by bradley13
• It's from 2019, so it's hardly a recent development.

  It's also very discoverable if you see it in the wild. You may be surprised that `--` doesn't work, but you won't be surprised `--end-of-options` represents the end of options.

  What problem does this actually cause you? What additional complexity has adding this feature added to your development cycle?

  by windward
• The only way out is malleable software. Have the core data structures and algorithms in a native library. Have a layer of JavaScript/Lua/LISP on top of that. Editable, customizable, reusable.

  This is not a theory. I work in such a system every day.

  git sort of tried that with plumbing/porcelain separation and bash scripts, but it did not quite work. It all became a C monolith with very peculiar UX.

  by gritzko
• why does someone have a filename beginning with a dash?

  Because it's my computer, not yours, and I'll do what I want with it?

  by reaperducer
• > why does someone have a filename beginning with a dash? Maybe don't do tha

  Oh, the famous "you're holding it wrong". For one, that's a ridiculous limitation to place on the user, that's a pretty basic symbol, but also imagine someone else did that and you can't change it because it's outside of your control

  by eviks
• Sometimes you're using git in a context where you don't control the filenames, or where a potential attacker could influence or fully control them, at which point edge cases like this can easily turn into exploits.

  I also chafe whenever I run into artificial restrictions on things like characters in names of things, because there's no good reason for them besides the laziness of developers or the limitations and inertia of existing systems that might be used under the hood, like DNS for instance.

  by zanecodes
• So I should name my next branch ‘--‘ is what I'm hearing :)
  by yobert
• Name it `-->result.txt`
  by SAI_Peregrinus
• Does anyone know why git broke the long standing convention of "--" early on? Kind of a nightmare for humans to use.

  Remembering app-specific one-offs is kind of the worst!

  by metadat
• One of the undeniable benefits of LLMs is that the end of guessing and remembering commands is now optional.

  Now we can all run important CLI programs like Zork without a 'command doesn't exist' to command ratio of 1:4

  by TZubiri
• Flags for Unix tools have never been friendly.
  by vips7L
• It's a bit of a mystery, especially since the one of the lowest surprise character they could have chosen was a colon, and indeed colon is already used to separate branch and path -- but only where they are one option and not two.

  For example:

    git log mybranch myfile.txt
  

  but:

    git show mybranch:myfile.txt
  

  That's indeed one of the things that trip up people when I try to introduce them to the git model. I wish it had been different.

  The double dash is normally not needed when it is self evident if a branch or file is referred to. It is only needed when a file no longer exists or a file and a branch exists with the same name. One could easily have imagined the one-argument syntax to be dominant. It would have been a bit awkward in a few situations, but a lot less confusing in others.

  by xorcist
• Since it separates out the pathspec, doesn't that match the long standing convention?
  by epistasis
• When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
  by p-e-w
• The Single UNIX Specification mentions the "--" convention in 1997 (at which point it was already in widespread use): https://pubs.opengroup.org/onlinepubs/7908799/xbd/utilconv.h...

  The first release of git was in 2005, and Torvalds' Linux was clearly UNIX-inspired, so it's not like this was due to considerations for some other OS like DOS/Windows.

  by userbinator