git's –end-of-options Flag(nesbitt.io)
84 pointsby Erenay092 days ago10 comments
  • metadat2 hours ago
    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!

    • doctoboggan2 hours ago
      git's data model is incredibly powerful and flexible, but its UX is famously... interesting:

      https://stevelosh.com/blog/2013/04/git-koans/

    • userbinator32 minutes ago
      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.

      • j16sdiz20 minutes ago
        The practice was there before the spec
    • epistasis2 hours ago
      Since it separates out the pathspec, doesn't that match the long standing convention?
    • TZubiri35 minutes ago
      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

      • xg1525 minutes ago
        Yeah, now the LLMs are guessing the commands...
    • p-e-w2 hours ago
      When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
  • yobert2 hours ago
    So I should name my next branch ‘--‘ is what I'm hearing :)
    • fragmede2 hours ago
      just don't call it master
      • randunelan hour ago
        That's still the default in my localhost, but I get a warning that it'll change.
      • 4gotunameagain32 minutes ago
        One of the most stupid virtue signaling changes of the industry.
  • Chinjutan hour ago
    The "Everything is text, do everything via text" philosophy has its advantages, and also its disadvantages.
    • usr1106an hour ago
      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.

  • 13 minutes ago
    undefined
  • epistasis2 hours ago
    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.
    • gene91an hour ago
      Currently, git log -- a -- prints all commits that affects the files whose name is a or two dashes.
  • bradley132 hours ago
    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.

    • zanecodes2 hours ago
      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.

  • an hour ago
    undefined
  • _blk2 hours ago
    > 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)

    • eru2 hours ago
      I don't think you need object orientation for that. Haskell and Rust solve these problems also just fine, without any OOP in sight.
      • desmaraispan hour ago
        In this specific case, the oop nature of powershell doesn't actually matter, just the fact it uses structured input instead of raw string.

        It's like passing a struct to a function instead of a badly serialized representation of a value

      • _blk2 hours ago
        Hmm, not sure I understand. How are those shell based?

        I agree that rust and haskell are not your typical OO (or not OO at all in a traditional sense) I guess my poorly worded claim was less focused on the OO nature of psh than on the typization (which both of these also do) - if you knew what type $rev and $path are, it's easier to distinguish intent, whether objects or not.

  • ButlerianJihad2 hours ago
    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.

    • wafflemaker2 hours ago
      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.
    • Erenay09an hour ago
      I'm sure I typed double-hyphen when submitting the post, but probably HN auto-formatted the title. IDK really.
    • sheeptan hour ago
      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.

      • ButlerianJihadan hour ago
        Okay, edit submitted, but that is extra weird, because the double hyphen is a convention or placeholder for an emdash. When a transformation takes place, it becomes an emdash.

        There is no reason to transform it to an endash. I don't know any software that would do that. Checked with an LLM, too. That makes no sense at all!

        • dasyatidprime25 minutes ago
          TeX uses -- (double hyphen) for producing an en dash and --- (triple hyphen) for an em dash, and that's pretty darn longstanding and well-established. And FWIW, the English writing conventions that I learned use em dashes as punctuation without an adjoining space—like this—but allow en dashes surrounded by spaces as an alternative – like this – so I frequently see spaced double hyphen used as the ASCII equivalent of dash punctuation and interpret it as the latter. I've never personally heard of double hyphen for em specifically, only either as en specifically or as a sort of ambiguous whatever-dash.
          • chowells2 minutes ago
            Double dash -> emdash is a default autoreplacement in OSX. That's why a lot of people think it's the default everywhere.
        • cubefox7 minutes ago
          Then how do you type in an en dash instead? Also, according to LLMs, the en dash is used in far more languages than the em dash. Many languages don't use the em dash at all. Using the em dash for sentence interruptions seems to be specifically an US American English tradition: Most languages which use dashes for sentence interruptions use spaced en dashes instead.
  • usr1106an hour ago
    Copilot CLI (we get that at work) often uses slightly low-level and cryptic git commands. Never noticed that it would use --end-of-options though.

    Should check what it does with branch names starting with a dash.

    Of course that wouldn't be a security vulnerability, but a user error. It asks user approvals to execute those things and has disclaimers to check results. Which of course every user does all the time... /s