git's –end-of-options Flag
nesbitt.io
nesbitt.io
Remembering app-specific one-offs is kind of the worst!
Especially because the text is actually written by a human, and it's clear from every sentence
no idea where I saw that though and it was many many years ago.
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.
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.
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.
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.
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).
git -h branch
git branch --help
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.
> 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.
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.
Now we can all run important CLI programs like Zork without a 'command doesn't exist' to command ratio of 1:4
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.
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.
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.
For example:
git log mybranch myfile.txt
git show mybranch:myfile.txt
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.
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.
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.
"User-controlled strings as parameters" is not "access to your git" but it is still an attack vector.
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
Because it's my computer, not yours, and I'll do what I want with it?
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?
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.
Don't see that we get rid of either command lines in text or von Neumann any time soon.
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/
The Unix-y world has been around for decades, so it many ways it has evolved rather than be designed.
The novice asked: "Master, what is the advantage of unstructured text over structured? Is it not mere adoption?"
Master Git said nothing and pointed to the first shop, kept by the old scrooge Postgre.
As they entered, Master Git said quietly, shaping his mouth funnily:
SELECT weight/2 FROM shelf WHERE name = ''
Next stood a shop kept by a bright newcomer, Duck D'Bee.
Master Git repeated:
SELECT weight/2 FROM shelf WHERE name = ''
Their journey ended at a giant abandoned building beneath a dead neon sign: ORCL. The door stood open. Inside, putrid odour and dust lay upon deflated balloons and faded banners saying A.I. The shelves were still full of unmarked boxes.
Master Git shouted into the dark:
SELECT weight/2 FROM shelf WHERE name = ''
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)
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.
A shell is just a programming language that's well suited for interactive repl use. Compare 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!
It's like passing a struct to a function instead of a badly serialized representation of a value
The saddest thing is even ASCII has characters to help with this but since keyboards can't type them nobody used them.
git cmd --options -- rev -- pathspec
git cmd --option -- rev --
git cmd --option revspec -- pathspec
git log -- -- a --By the way, something munched the article title. An endash is incorrect command-line usage. It’s supposed to be a double hyphen.
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.
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!
:---:
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.
KDE Plasma: Press-and-Hold for Alternative Characters https://blogs.kde.org/2026/03/14/this-week-in-plasma-press-a...
A /more recent/ convention.
My memory of early Associated Press computer systems is that two dashes is the endash (or "nutt") and three dashes is the emdash ("mutt").
Which seems unfair because what if they have subconsciously regurgitated Claude-speak?
[1] "That’s a real cost,"
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