8 ms·

git's –end-of-options Flag

184 points by ErenayDev 3mo ago

metadat 3mo 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!
- doctoboggan 3mo ago
  git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
  - peheje 3mo ago
    These are great
    - andy99 3mo ago
      I don’t understand any of them. Normally even when I’m not really familiar with a tool, I have enough background knowledge to understand why it’s funny e.g. Scheme and Haskell jokes or something. I do use basic git regularly and all of this is over my head. I don’t know if that speaks to how complicated and unintuitive some of the advanced stuff is?
      - jibal 3mo ago
        The context here is the statement that "its UX is famously... interesting". You don't have to understand anything other than how wildly inconsistent the git CLI is.
      - xigoi 3mo ago
        The second one is about how Git uses the word “checkout” for three unrelated operations, violating the Unix philosophy.
  - ffsm8 3mo ago
    It's always such a good experience to read well written articles like this from the early 2010s when our industry was a lot less self-important Especially because the text is actually written by a human, and it's clear from every sentence
    - dc3k 3mo ago
      I also appreciated that the site didn’t give me a popup asking me to sign up to its newsletter.
      - lukan 3mo ago
        I did not appreciate reading with a mobile, though. Text did not fit the screen, but FF reader mode fixed it.
  - Bugg4 3mo ago
    The hobgoblin one sent me
  - pydry 3mo ago
    iirc Linus actually conceded this very early on and said that he thought it would be better if it were used as infrastructure to build tools on rather than the tool itself. no idea where I saw that though and it was many many years ago.
    - edelbitter 3mo ago
      In any case, the refined version of that admission - the deliberate porcelain/plumbing distinction - is still best explained in the git docs and I wish more tools would copy it. apt(-get) has cautiously started that process, while GnuPG sadly remains a box shock full of surprises in both API and CLI.
    - inigyou 3mo ago
      I think at that point he only had the plumbing commands. Commands like "git commit" are the tools he meant.
    - mhh__ 3mo ago
      This is actually kind of happening! (In a way) There are, at this point, quite a few git-successors that either basically or literally use gits object model - git-butler, jujutsu, sapling (iirc). It's at worst good-enough.
  - ulrikrasmussen 3mo ago
    I use git every day and can do quite advanced stuff with it, but I do all of my work using magit in emacs. I don't even use emacs for writing code anymore, I only use it for git. I just can't be bothered with using the CLI, it is too painfully inconsistent. The only downside to this is that it is hard for me to help people with git problems since I can only tell them what conceptually has to be done, not how to accomplish it using the CLI.
    - IshKebab 3mo ago
      When beginners need help with Git and they're using the CLI the first and best advice I give them is to stop using the CLI.
      - sigseg1v 3mo ago
        This is interesting to me because when beginners come to me for help with git and they're using a GUI, the first thing I do is tell them to ditch it and learn the CLI.
        IshKebab 3mo ago
        Hasn't been my experience at all, but also why would you do that? The CLI has an awful confusing UX and also doesn't easily show you the state of things. If you're trying to teach a child how filesystems work, do you open a terminal and teach them `ls` and `cd`? No of course not. You use some kind of GUI file manager with a tree view.
        dns_snek 3mo ago
        git CLI and various GUIs are awful in different ways. CLI is awfully inconsistent and hard to learn, but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes.
        IshKebab 3mo ago
        > but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes. I disagree. "What's happening behind the scenes" is not the corresponding CLI command - it's the actual modification to the commit graph, and GUIs are much better at exposing what is happening. Think about something like a rebase. Find any article explaining Git rebase. It will have diagrams showing what happens to the commits and those diagrams are exactly what a Git GUI displays! To follow my filesystem analogy, when you move a file, the thing that's happening behind the scenes is that the file is moved, not `mv A B`. > make it harder to recover from mistakes. Also disagree. I'm not sure what you're talking about exactly but assuming reflog, then most GUIs don't support that and you're going to have to use the CLI in either case. But "GUIs don't cover this rare feature" isn't a reason to ditch them completely. I agree there are a lot of awful GUIs though. It doesn't help that the Git website lists dozens of them and only 2 or 3 are any good. My recommendation: if you use VSCode, the Git Graph extension. If you want a standalone tools, SourceGit or maybe GitX if you're on Mac.
  - inigyou 3mo ago
    TortoiseGit was very cool, and nothing stops us making more alternative UXes. I miss the extensibility of Windows, back when programs still fought for the users (Tron reference). Shell extensions, COM/OLE, ActiveX controls. Sure they were annoying but they actually did stuff that we just can't do any more. Even start menu folders with more than one entry. It was like each thing you installed could be a plugin for your whole computer, not just an isolated space where you visit sometimes (the iOS model).
  - inigyou 3mo ago
    [flagged]
  - freehorse 3mo ago
    I puzzled over the "The Long and Short of It" as for me (git version 2.54.0) git -h branch gives the same output as git branch --help so I could not understand why master git jumped and died. But it seems that in older versions it threw an argument error according to the old discussion [0]. I see that `git -h branch`, `git branch --help` and `git --help branch` give the long output but `git branch -h` gives the short. I suspect that `git [-h | --help] branch` is converted to `git help branch` which runs `help` with argument `branch`. But `git branch -h` runs `branch` with argument `-h`. Also as `git -h alias` prints the alias definition while `git alias -h` gives the short help for the aliased command. [0] https://news.ycombinator.com/item?id=5512103 https://news.ycombinator.com/item?id=5512103
- p-e-w 3mo ago
  When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
- epistasis 3mo ago
  Since it separates out the pathspec, doesn't that match the long standing convention?
  - jibal 3mo ago
    The convention is that a leading `-` isn't recognized as a flag after `--`.
    - epistasis 3mo ago
      Yes, doesn't that match git's behavior? Or are you saying that's not the case?
      - jibal 3mo ago
        Why would `--end-of-options` be needed if `--` always signals the end of options? Please read the article.
        epistasis 2mo ago
        Please do not rudely assume I have not read the article. Let me show you what the article says: > But that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions. In git, `--` specifies where the options end and the files begin, just as it does for `rm` and other unix conventions. Just exactly as you said, `-` is not recognized as an option after `--`. So git is following the Unix convention, both as you have described the convention, and as I understand the convention.
        jibal 2mo ago
        It wasn't rude to think that this person might not have read the article, when what they write doesn't account for what the article says. What's rude is to not answer the question: "Why would --end-of-options be needed if -- always signals the end of options?" and to instead just repeat the claim that git is following the UNIX convention when it clearly does not, as their own quotes says: "that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions." i.e., `--` is used as a separator, not as a signal that no further leading `-` is significant.
- TZubiri 3mo 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
  - xg15 3mo ago
    Yeah, now the LLMs are guessing the commands...
    - gritzko 3mo ago
      Spot on. I had my repo messed up more than once. Sometimes it is quick enough to push that to GitHub.
- userbinator 3mo 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.html#tag_009_002 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.
  - j16sdiz 3mo ago
    The practice was there before the spec
    - setopt 3mo ago
      Which the parent poster said in their comment?
- vips7L 3mo ago
  Flags for Unix tools have never been friendly.
  - VBprogrammer 3mo ago
    Find is a great example. It's such a useful and powerful tool but it's arguments get me on a regular basis.
- dmurray 3mo ago
  It sounds like they didn't need (at the time) to separate arguments from options, but they did need to separate revisions from pathspecs. So they repurposed "--" as the most familiar separator. Probably they were trying to use familiar conventions, but when they later needed to separate arguments from options, that was a closer match for what other people were using "--" for, but it was too late.
  - stingraycharles 3mo ago
    So basically don’t break conventions by repurposing existing operators for something else. It’s silly as git is otherwise a very elegantly designed application, and you’d expect it to be developed by people who are very accustomed to these conventions.
    - zoky 3mo ago
      As a primarily FreeBSD user who feels like I have to relearn the idiosyncrasies of practically the entire system every I install a new Linux distro, the mess of configuration options somehow actually seems entirely on-brand to me.
- xorcist 3mo ago
  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.
yobert 3mo ago
So I should name my next branch ‘--‘ is what I'm hearing :)
- fragmede 3mo ago
  [flagged]
  - randunel 3mo ago
    That's still the default in my localhost, but I get a warning that it'll change.
    - inigyou 3mo ago
      You can set it in the config to whatever you want and the warning goes away. The whole default branch name change was a terrible idea that caused many more problems than it solved—as was already pointed out at the time. But if you're going to set a name anyway, may as well call it trunk, or dominatrix, depending upon today's silliness level.
  - 4gotunameagain 3mo ago
    [flagged]
    - oneeyedpigeon 3mo ago
      There are advantages beyond avoiding the use of a charged term.
      - jchw 3mo ago
        It wasn't a charged term and there are not.
      - fragmede 3mo ago
        to be fair, I like typing less, and main is shorter than master.
_blk 3mo 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)
- eru 3mo 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.
  - _blk 3mo 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.
    - eru 3mo ago
      > Hmm, not sure I understand. How are those shell based? A shell is just a programming language that's well suited for interactive repl use. Compare https://en.wikipedia.org/wiki/Scsh https://en.wikipedia.org/wiki/Scsh Of course, Rust and Haskell aren't typically thought of as shells. Though if you wanted to and felt brave enough, you could use ghci as a shell. > 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. Agreed!
  - desmaraisp 3mo 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
ButlerianJihad 3mo ago
https://m.xkcd.com/1597/ 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.
- wafflemaker 3mo 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.
  - ButlerianJihad 3mo ago
    I'm sorry, you've learned what now?
- ErenayDev 3mo ago
  I'm sure I typed double-hyphen when submitting the post, but probably HN auto-formatted the title. IDK really.
- sheept 3mo 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.
  - ButlerianJihad 3mo 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!
    - dasyatidprime 3mo ago
bradley13 3mo 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.
- zanecodes 3mo 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.
  - vips7L 3mo ago
    An attacker has access to your git??? You’re fucked. Give up.
    - kangalioo 3mo ago
      Every git repository hosting platform - GitHub, GitLab, Bitbucket, Codeberg - necessarily gives end users control over filenames. "User-controlled strings as parameters" is not "access to your git" but it is still an attack vector.
- eviks 3mo ago
  > 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
  - 3mo ago
epistasis 3mo 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.
- gene91 3mo ago
  Currently, git log -- a -- prints all commits that affects the files whose name is a or two dashes.
  - epistasis 3mo ago
    Yes, that would change behavior slightly. To restore behavior for pathspecs including a "--" file, you would need to add an additional -- to make the revspec explicitly blank: git log -- -- a --
    - gene91 3mo ago
      Previously working command needs to continue behave the same way. Your original proposal was intended to provide backward compatibility (your third point in original comment), and that’s an important part of why it could work.
- peff 3mo ago
  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".
  - epistasis 3mo ago
    Add in "--" a third time, and it's a file in the path spec, like it is for tools like rm.
Chinjut 3mo ago
The "Everything is text, do everything via text" philosophy has its advantages, and also its disadvantages.
- usr1106 3mo 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.
- eviks 3mo ago
  What are the advantages over structured text?
  - majewsky 3mo ago
    Access to a well-established set of tools for operating on unstructured text (coreutils, grep, sed, awk, etc.).
    - eviks 3mo ago
      That's not the benefit of text, just adoption. All these tools could've just as well grown to be popular with a proper format, and your point would be exactly the same
      - psd1 3mo ago
        You're damned right - much better is possible than the gnu tools. I'm one of the savages using pwsh on Linux (the other two are still on reddit). I have no need for sed/awk ascii salad, and jq can fuck off into the far distance.
      - throw0101d 3mo ago
        > All these tools could've just as well grown to be popular with a proper format, and your point would be exactly the same And what would this "proper format" be? Currently JSON is in vogue (or JSON5, which allows comments?), but a few years ago it would have been XML, before that… CSV? TSV? Or perhaps do a Choose Your Own Adventure: * https://libxo.readthedocs.io/ https://libxo.readthedocs.io/ The Unix-y world has been around for decades, so it many ways it has evolved rather than be designed.
deleted 3mo ago
[deleted]
usr1106 3mo 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
- vips7L 3mo ago
  Absolute another level of lazy if you need an LLM to git for you.
deleted 3mo ago
[deleted]
luciana1u 3mo ago
[flagged]
xyzsparetimexyz 3mo ago
What a mess. Just use jj instead.
deleted 3mo ago
[deleted]
sawrtagy 3mo ago
[dead]
bombcar 3mo ago
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.
- Gormo 3mo ago
  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.
deleted 3mo ago
[deleted]
angry_octet 3mo ago
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,"

184 points by ErenayDev 3mo 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!

doctoboggan 3mo ago
git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
- peheje 3mo ago
  These are great
  - andy99 3mo ago
    I don’t understand any of them. Normally even when I’m not really familiar with a tool, I have enough background knowledge to understand why it’s funny e.g. Scheme and Haskell jokes or something. I do use basic git regularly and all of this is over my head. I don’t know if that speaks to how complicated and unintuitive some of the advanced stuff is?
    - jibal 3mo ago
      The context here is the statement that "its UX is famously... interesting". You don't have to understand anything other than how wildly inconsistent the git CLI is.
    - xigoi 3mo ago
      The second one is about how Git uses the word “checkout” for three unrelated operations, violating the Unix philosophy.
- ffsm8 3mo ago
  It's always such a good experience to read well written articles like this from the early 2010s when our industry was a lot less self-important Especially because the text is actually written by a human, and it's clear from every sentence
  - dc3k 3mo ago
    I also appreciated that the site didn’t give me a popup asking me to sign up to its newsletter.
    - lukan 3mo ago
      I did not appreciate reading with a mobile, though. Text did not fit the screen, but FF reader mode fixed it.
- Bugg4 3mo ago
  The hobgoblin one sent me
- pydry 3mo ago
  iirc Linus actually conceded this very early on and said that he thought it would be better if it were used as infrastructure to build tools on rather than the tool itself. no idea where I saw that though and it was many many years ago.
  - edelbitter 3mo ago
    In any case, the refined version of that admission - the deliberate porcelain/plumbing distinction - is still best explained in the git docs and I wish more tools would copy it. apt(-get) has cautiously started that process, while GnuPG sadly remains a box shock full of surprises in both API and CLI.
  - inigyou 3mo ago
    I think at that point he only had the plumbing commands. Commands like "git commit" are the tools he meant.
  - mhh__ 3mo ago
    This is actually kind of happening! (In a way) There are, at this point, quite a few git-successors that either basically or literally use gits object model - git-butler, jujutsu, sapling (iirc). It's at worst good-enough.
- ulrikrasmussen 3mo ago
  I use git every day and can do quite advanced stuff with it, but I do all of my work using magit in emacs. I don't even use emacs for writing code anymore, I only use it for git. I just can't be bothered with using the CLI, it is too painfully inconsistent. The only downside to this is that it is hard for me to help people with git problems since I can only tell them what conceptually has to be done, not how to accomplish it using the CLI.
  - IshKebab 3mo ago
    When beginners need help with Git and they're using the CLI the first and best advice I give them is to stop using the CLI.
    - sigseg1v 3mo ago
      This is interesting to me because when beginners come to me for help with git and they're using a GUI, the first thing I do is tell them to ditch it and learn the CLI.
      - IshKebab 3mo ago
        Hasn't been my experience at all, but also why would you do that? The CLI has an awful confusing UX and also doesn't easily show you the state of things. If you're trying to teach a child how filesystems work, do you open a terminal and teach them `ls` and `cd`? No of course not. You use some kind of GUI file manager with a tree view.
        dns_snek 3mo ago
        git CLI and various GUIs are awful in different ways. CLI is awfully inconsistent and hard to learn, but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes.
        IshKebab 3mo ago
        > but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes. I disagree. "What's happening behind the scenes" is not the corresponding CLI command - it's the actual modification to the commit graph, and GUIs are much better at exposing what is happening. Think about something like a rebase. Find any article explaining Git rebase. It will have diagrams showing what happens to the commits and those diagrams are exactly what a Git GUI displays! To follow my filesystem analogy, when you move a file, the thing that's happening behind the scenes is that the file is moved, not `mv A B`. > make it harder to recover from mistakes. Also disagree. I'm not sure what you're talking about exactly but assuming reflog, then most GUIs don't support that and you're going to have to use the CLI in either case. But "GUIs don't cover this rare feature" isn't a reason to ditch them completely. I agree there are a lot of awful GUIs though. It doesn't help that the Git website lists dozens of them and only 2 or 3 are any good. My recommendation: if you use VSCode, the Git Graph extension. If you want a standalone tools, SourceGit or maybe GitX if you're on Mac.
- inigyou 3mo ago
  TortoiseGit was very cool, and nothing stops us making more alternative UXes. I miss the extensibility of Windows, back when programs still fought for the users (Tron reference). Shell extensions, COM/OLE, ActiveX controls. Sure they were annoying but they actually did stuff that we just can't do any more. Even start menu folders with more than one entry. It was like each thing you installed could be a plugin for your whole computer, not just an isolated space where you visit sometimes (the iOS model).
- inigyou 3mo ago
  [flagged]
- freehorse 3mo ago
  I puzzled over the "The Long and Short of It" as for me (git version 2.54.0) git -h branch gives the same output as git branch --help so I could not understand why master git jumped and died. But it seems that in older versions it threw an argument error according to the old discussion [0]. I see that `git -h branch`, `git branch --help` and `git --help branch` give the long output but `git branch -h` gives the short. I suspect that `git [-h | --help] branch` is converted to `git help branch` which runs `help` with argument `branch`. But `git branch -h` runs `branch` with argument `-h`. Also as `git -h alias` prints the alias definition while `git alias -h` gives the short help for the aliased command. [0] https://news.ycombinator.com/item?id=5512103 https://news.ycombinator.com/item?id=5512103
p-e-w 3mo ago
When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
epistasis 3mo ago
Since it separates out the pathspec, doesn't that match the long standing convention?
- jibal 3mo ago
  The convention is that a leading `-` isn't recognized as a flag after `--`.
  - epistasis 3mo ago
    Yes, doesn't that match git's behavior? Or are you saying that's not the case?
    - jibal 3mo ago
      Why would `--end-of-options` be needed if `--` always signals the end of options? Please read the article.
      - epistasis 2mo ago
        Please do not rudely assume I have not read the article. Let me show you what the article says: > But that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions. In git, `--` specifies where the options end and the files begin, just as it does for `rm` and other unix conventions. Just exactly as you said, `-` is not recognized as an option after `--`. So git is following the Unix convention, both as you have described the convention, and as I understand the convention.
      - jibal 2mo ago
        It wasn't rude to think that this person might not have read the article, when what they write doesn't account for what the article says. What's rude is to not answer the question: "Why would --end-of-options be needed if -- always signals the end of options?" and to instead just repeat the claim that git is following the UNIX convention when it clearly does not, as their own quotes says: "that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions." i.e., `--` is used as a separator, not as a signal that no further leading `-` is significant.
TZubiri 3mo 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
- xg15 3mo ago
  Yeah, now the LLMs are guessing the commands...
  - gritzko 3mo ago
    Spot on. I had my repo messed up more than once. Sometimes it is quick enough to push that to GitHub.
userbinator 3mo 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.html#tag_009_002 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.
- j16sdiz 3mo ago
  The practice was there before the spec
  - setopt 3mo ago
    Which the parent poster said in their comment?
vips7L 3mo ago
Flags for Unix tools have never been friendly.
- VBprogrammer 3mo ago
  Find is a great example. It's such a useful and powerful tool but it's arguments get me on a regular basis.
dmurray 3mo ago
It sounds like they didn't need (at the time) to separate arguments from options, but they did need to separate revisions from pathspecs. So they repurposed "--" as the most familiar separator. Probably they were trying to use familiar conventions, but when they later needed to separate arguments from options, that was a closer match for what other people were using "--" for, but it was too late.
- stingraycharles 3mo ago
  So basically don’t break conventions by repurposing existing operators for something else. It’s silly as git is otherwise a very elegantly designed application, and you’d expect it to be developed by people who are very accustomed to these conventions.
  - zoky 3mo ago
    As a primarily FreeBSD user who feels like I have to relearn the idiosyncrasies of practically the entire system every I install a new Linux distro, the mess of configuration options somehow actually seems entirely on-brand to me.
xorcist 3mo ago
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.

yobert 3mo ago

So I should name my next branch ‘--‘ is what I'm hearing :)

fragmede 3mo ago
[flagged]
- randunel 3mo ago
  That's still the default in my localhost, but I get a warning that it'll change.
  - inigyou 3mo ago
    You can set it in the config to whatever you want and the warning goes away. The whole default branch name change was a terrible idea that caused many more problems than it solved—as was already pointed out at the time. But if you're going to set a name anyway, may as well call it trunk, or dominatrix, depending upon today's silliness level.
- 4gotunameagain 3mo ago
  [flagged]
  - oneeyedpigeon 3mo ago
    There are advantages beyond avoiding the use of a charged term.
    - jchw 3mo ago
      It wasn't a charged term and there are not.
    - fragmede 3mo ago
      to be fair, I like typing less, and main is shorter than master.

_blk 3mo 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)

eru 3mo 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.
- _blk 3mo 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.
  - eru 3mo ago
    > Hmm, not sure I understand. How are those shell based? A shell is just a programming language that's well suited for interactive repl use. Compare https://en.wikipedia.org/wiki/Scsh https://en.wikipedia.org/wiki/Scsh Of course, Rust and Haskell aren't typically thought of as shells. Though if you wanted to and felt brave enough, you could use ghci as a shell. > 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. Agreed!
- desmaraisp 3mo 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

ButlerianJihad 3mo ago

https://m.xkcd.com/1597/ 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.

wafflemaker 3mo 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.
- ButlerianJihad 3mo ago
  I'm sorry, you've learned what now?
ErenayDev 3mo ago
I'm sure I typed double-hyphen when submitting the post, but probably HN auto-formatted the title. IDK really.
sheept 3mo 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.
- ButlerianJihad 3mo 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!
  - dasyatidprime 3mo ago

bradley13 3mo 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.

zanecodes 3mo 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.
- vips7L 3mo ago
  An attacker has access to your git??? You’re fucked. Give up.
  - kangalioo 3mo ago
    Every git repository hosting platform - GitHub, GitLab, Bitbucket, Codeberg - necessarily gives end users control over filenames. "User-controlled strings as parameters" is not "access to your git" but it is still an attack vector.
eviks 3mo ago
> 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
- 3mo ago

epistasis 3mo 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.

gene91 3mo ago
Currently, git log -- a -- prints all commits that affects the files whose name is a or two dashes.
- epistasis 3mo ago
  Yes, that would change behavior slightly. To restore behavior for pathspecs including a "--" file, you would need to add an additional -- to make the revspec explicitly blank: git log -- -- a --
  - gene91 3mo ago
    Previously working command needs to continue behave the same way. Your original proposal was intended to provide backward compatibility (your third point in original comment), and that’s an important part of why it could work.
peff 3mo ago
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".
- epistasis 3mo ago
  Add in "--" a third time, and it's a file in the path spec, like it is for tools like rm.

Chinjut 3mo ago

The "Everything is text, do everything via text" philosophy has its advantages, and also its disadvantages.

usr1106 3mo 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.
eviks 3mo ago
What are the advantages over structured text?
- majewsky 3mo ago
  Access to a well-established set of tools for operating on unstructured text (coreutils, grep, sed, awk, etc.).
  - eviks 3mo ago
    That's not the benefit of text, just adoption. All these tools could've just as well grown to be popular with a proper format, and your point would be exactly the same
    - psd1 3mo ago
      You're damned right - much better is possible than the gnu tools. I'm one of the savages using pwsh on Linux (the other two are still on reddit). I have no need for sed/awk ascii salad, and jq can fuck off into the far distance.
    - throw0101d 3mo ago
      > All these tools could've just as well grown to be popular with a proper format, and your point would be exactly the same And what would this "proper format" be? Currently JSON is in vogue (or JSON5, which allows comments?), but a few years ago it would have been XML, before that… CSV? TSV? Or perhaps do a Choose Your Own Adventure: * https://libxo.readthedocs.io/ https://libxo.readthedocs.io/ The Unix-y world has been around for decades, so it many ways it has evolved rather than be designed.

deleted 3mo ago

[deleted]

usr1106 3mo 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

vips7L 3mo ago
Absolute another level of lazy if you need an LLM to git for you.

deleted 3mo ago

[deleted]

luciana1u 3mo ago

[flagged]

xyzsparetimexyz 3mo ago

What a mess. Just use jj instead.

deleted 3mo ago

[deleted]

sawrtagy 3mo ago

[dead]

bombcar 3mo ago

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.

Gormo 3mo ago
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.

deleted 3mo ago

[deleted]

angry_octet 3mo ago

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,"