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
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.
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.
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.
Now we can all run important CLI programs like Zork without a 'command doesn't exist' to command ratio of 1:4
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.
Don't see that we get rid of either command lines in text or von Neumann any time soon.
The saddest thing is even ASCII has characters to help with this but since keyboards can't type them nobody used them.
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)
git cmd --options -- rev -- pathspec
git cmd --option -- rev --
git cmd --option revspec -- pathspec
[deleted]
Which seems unfair because what if they have subconsciously regurgitated Claude-speak?
[1] "That’s a real cost,"
[deleted]
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.
[deleted]
[deleted]
[dead]
[dead]
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
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).
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.
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.
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.
[dead]
> 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.
[dead]
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.
[dead]
"User-controlled strings as parameters" is not "access to your git" but it is still an attack vector.
Because it's my computer, not yours, and I'll do what I want with it?
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
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.
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?
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 = ''
It's like passing a struct to a function instead of a badly serialized representation of a value
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!
git log -- -- a --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").
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.
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.
[dead]
The word "master" is of course still in widespread use elsewhere too. We still say "Master's degree" or "mastering a skill".
The point of this entire exercise was group dynamics, but what I hate most about it is something that I also hate about other recent bullshit: I hate that not wanting to play is in itself forced to be an active stance. I have no reason or desire to change my default branch name; it is staying master. That is not an attempt to signal anything at all. This is not "chud-coded". It is literally, the absence of a desire to participate.
And we'll never forget it either, because now even in pre-existing projects we have to checkout/pull master then main. Or worse. You know how many times I've accidentally rebased off of an ancient version of something because master still exists? This is surprisingly common.
It was an entire waste of time and everyone who has remaining respect for themselves should be honest about it.
[deleted]
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.
I agree with this position, and yet I would argue that, by taking the time to write out this comment, you are acting inconsistenly with your own statement.
I have old repos with "master" and new repos with "main". If someone were to approach me about one of the old repos and ask about the default branch, I would immediately change it to "main" without any hesitation, because it is all but certain that trying to get into an argument will waste more of my time than just doing the change would.
And you're absolutely entitled to. I have no problem with anyone choosing to stick with "master", provided they have no issue with me preferring "main".
It's not a big annoyance but it is an especially painful one because it didn't used to exist and it was deliberately introduced for completely bullshit reasons.