Does anyone know why git broke the long standing convention of "--" early on? Kind of a nightmare for humans to use.<p>Remembering app-specific one-offs is kind of the worst!
git's data model is incredibly powerful and flexible, but its UX is famously... interesting:<p><a href="https://stevelosh.com/blog/2013/04/git-koans/" rel="nofollow">https://stevelosh.com/blog/2013/04/git-koans/</a>
TortoiseGit was very cool, and nothing stops us making more alternative UXes.<p>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).
I puzzled over the "The Long and Short of It" as for me (git version 2.54.0)<p><pre><code> git -h branch
</code></pre>
gives the same output as<p><pre><code> git branch --help
</code></pre>
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].<p>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.<p>[0] <a href="https://news.ycombinator.com/item?id=5512103">https://news.ycombinator.com/item?id=5512103</a>
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<p>Especially because the text is actually written by a human, and it's clear from every sentence
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.<p>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.
I don't fully agree with the checkout one. We <i>do</i> speak of checking out a file and checking out a branch using the same word, and they are not the same thing.<p>checkout -b however makes no sense. It should be the default behavior of git branch. It was probably put under checkout because it made for more straightforward code.
These are great
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?
The second one is about how Git uses the word “checkout” for three unrelated operations, violating the Unix philosophy.
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.
The hobgoblin one sent me
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.<p>no idea where I saw that though and it was many many years ago.
This is actually kind of happening! (In a way)<p>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.
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.
I think at that point he only had the plumbing commands. Commands like "git commit" <i>are</i> the tools he meant.
The <i>Single UNIX Specification</i> mentions the "--" convention in 1997 (at which point it was already in widespread use): <a href="https://pubs.opengroup.org/onlinepubs/7908799/xbd/utilconv.html#tag_009_002" rel="nofollow">https://pubs.opengroup.org/onlinepubs/7908799/xbd/utilconv.h...</a><p>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.
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.<p>Probably they <i>were</i> 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.
Since it separates out the pathspec, doesn't that match the long standing convention?
When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
Flags for Unix tools have never been friendly.
One of the undeniable benefits of LLMs is that the end of guessing and remembering commands is now optional.<p>Now we can all run important CLI programs like Zork without a 'command doesn't exist' to command ratio of 1:4
So I should name my next branch ‘--‘ is what I'm hearing :)
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.<p>The saddest thing is even ASCII has characters to help with this but since keyboards can't type them nobody used them.
As with almost any successful system: more and more special features and edge cases get added. Git has become ridiculously complex.<p>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.
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.<p>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.
> why does someone have a filename beginning with a dash? Maybe don't do tha<p>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
It's a problem with mixing code and data, therefore needing to escape. You can solve it by adding another symbol, let's call it Options Introducer, but that doesn't actually solve it because someone can name a file starting with Options Introducer. GUIs don't have this problem because you are clearly typing in the textbox or outside of it, or even better, you can select the file you mean.
It's from 2019, so it's hardly a recent development.<p>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.<p>What problem does this actually cause you? What additional complexity has adding this feature added to your development cycle?
<i>why does someone have a filename beginning with a dash?</i><p>Because it's my computer, not yours, and I'll do what I want with it?
The "Everything is text, do everything via text" philosophy has its advantages, and also its disadvantages.
Like the von Neumann architecture. Your data can be misused as code.<p>Don't see that we get rid of either command lines in text or von Neumann any time soon.
What are the advantages over structured text?
Long-term compatibility and the avoidance of vendor lock-in.
Access to a well-established set of tools for operating on unstructured text (coreutils, grep, sed, awk, etc.).
Perhaps I'm missing something (it's been a long day), but couldn't "--" be used for both?<p><pre><code> git cmd --options -- rev -- pathspec
</code></pre>
would be the fully specified revspec and pathspec<p><pre><code> git cmd --option -- rev --
</code></pre>
would be just the revspec, excluding accidental options, without a pathspec<p><pre><code> git cmd --option revspec -- pathspec
</code></pre>
and the single "--" would work as it currently does.
Currently, git log -- a -- prints all commits that affects the files whose name is a or two dashes.
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".
> git log --end-of-options "$rev" -- "$path",<p>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)
<a href="https://m.xkcd.com/1597/" rel="nofollow">https://m.xkcd.com/1597/</a><p>By the way, something munched the article title. An endash is incorrect command-line usage. It’s supposed to be a double hyphen.
It is an en dash, not an em dash, since it's about as wide as an n.<p>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.
Okay, edit submitted, but that is <i>extra weird</i>, because the double hyphen is a convention or placeholder for an <i>emdash</i>. When a transformation takes place, it becomes an emdash.<p>There is <i>no reason</i> 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!
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>I</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.
On Linux, the en dash is typed with `[Compose]--.` and the em dash with `[Compose]---`.
Unless, you know, you configured it to work differently. I'm using [Compose]nd and [Compose]md . And a bunch of other cute things, like [Compose][Compose] for escape (with Caps Lock as my compose key).
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.
> how do you type in an en dash instead?<p>By pressing the "-" key for half a second and choosing the exact dash character I am looking for in the pop-up that shows near the caret.<p>KDE Plasma: Press-and-Hold for Alternative Characters
<a href="https://blogs.kde.org/2026/03/14/this-week-in-plasma-press-and-hold-for-alternative-characters/" rel="nofollow">https://blogs.kde.org/2026/03/14/this-week-in-plasma-press-a...</a>
I get en dash with alt+- and em dash with alt+shift+-. One of the niceties of the macOS keyboard layouts. There’s also the ellipsis and middot among other things.
<i>because the double hyphen is a convention or placeholder for an emdash</i><p>A /more recent/ convention.<p>My memory of early Associated Press computer systems is that two dashes is the endash (or "nutt") and three dashes is the emdash ("mutt").
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.
I'm sure I typed double-hyphen when submitting the post, but probably HN auto-formatted the title. IDK really.
What a mess. Just use jj instead.
[dead]
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.<p>Should check what it does with branch names starting with a dash.<p>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
[dead]