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).
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.
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.
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.
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.
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.
> 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.
It may surprise you to discover that children are quite capable of visualizing filesystem trees without a GUI, and learning `cd` and `ls` may lead them to experiment with `ls -R`, and learning the semantics of '.' and '..'
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It wasn't anyways. It was clearly in reference to "master copy", which is also not a charged term. Neither was "master bedroom". Hell, for most of my life I'd never even seen anyone raise objections over the master/slave dichotomy used in software and hardware either, which is a far easier to understand argument. It's all very recent, last decade and some change, despite many of these terms having come into use after the abolishment of slavery in the U.S.
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.
> It is literally, the absence of a desire to participate.
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.
My desire to not participate does not mean that I don't want to ever talk about it or that I am trying to minimize time wasted arguing about it. Hell, I'm happy to waste time arguing about anything, really. Especially if it's something that annoys me.
> I have no reason or desire to change my default branch name
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".
But I do have an issue with you preferring `main`. It means I have the constant annoyance of remembering whether a project uses `main` or `master`.
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.
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.
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.
> 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
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.
The only way out is malleable software. Have the core data structures and algorithms in a native library. Have a layer of JavaScript/Lua/LISP on top of that. Editable, customizable, reusable.
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.
JJ's use of the Git file format is done via https://github.com/GitoxideLabs/gitoxide -- there's still some missing features in the networking part, but the local-file-manipulation features are fully there.
Great lib. I meant libdog, a different thing. gitoxide is like "git implemented in Rust" while libdog is "git's necessary primitives in C" (objects, packs, sync proto, own index format, diff/merge, etc). As a result, gitoxide is 270KLoC while libdog is 24KLoC, plus 44KLoC of tokenizers. libdog uses token-level algorithms for diff, merge, blame. It also does syntax highlighting in the pager - they all need grammars.
It's from 2019, so it's hardly a recent development.
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?
“Surprised” is not the emotion I would describe when discovering yet another legacy of the insufferable verbosity of EMACS Lisp that the insufferably verbose Stallman loved to spell everything out and create insufferable “new standards” because his autocomplete environment was insufferably superior to everyone else.
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
Master Git and a novice were walking to the market to collect alms.
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 = ''
Postgre, long weary of Master's wisdoms, took a weight of three from the nameless shelf and cut it unevenly. The whole piece he pressed into the novice's bowl; the larger part, he kept for himself.
Next stood a shop kept by a bright newcomer, Duck D'Bee.
Master Git repeated:
SELECT weight/2 FROM shelf WHERE name = ''
Duck D'Bee smiled, carefully took an unnamed jar from a vertical stack and handed over one piece and half of another.
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 = ''
Silence was the reply. At this point the novice became enlightened.
> 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?
Yes, the lack of good design in that world is apparent and will continue to cripple a few more generations (but re. evolution that's often a false reading - in many cases it's some primitive napkin design made at the beginning of those decades that stuck without much evolution), but you've wandered into the wrong thread - it's not about the single best format that could've been, just about a circular logic flaw in the argument
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.
How can text enable compabitility if you can't be certain how to parse it, and the rules can change any time???
Similarly with vendors - how can they lock you into themselves if you use some widespread open format?
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.
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.
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:
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.
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".
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)
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.
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.
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.
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!
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.
LibreOffice is the same, double hyphen is en-dash and to get an em-dash you have to type:
:---:
I thought this was part of why it became an LLM signifier, most people can't tell the difference between the two visually and as far as I knew en-dash is what you usually get by accident, while LLMs use em-dash.
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.
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.
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).
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.
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
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!
git's data model is incredibly powerful and flexible, but its UX is famously... interesting:
https://stevelosh.com/blog/2013/04/git-koans/
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
I also appreciated that the site didn’t give me a popup asking me to sign up to its newsletter.
I did not appreciate reading with a mobile, though. Text did not fit the screen, but FF reader mode fixed it.
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).
I puzzled over the "The Long and Short of It" as for me (git version 2.54.0)
gives the same output as 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
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.
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.
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.
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.
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.
> 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.
It may surprise you to discover that children are quite capable of visualizing filesystem trees without a GUI, and learning `cd` and `ls` may lead them to experiment with `ls -R`, and learning the semantics of '.' and '..'
That would surprise me a great deal if it were true.
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.
no idea where I saw that though and it was many many years 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.
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.
I think at that point he only had the plumbing commands. Commands like "git commit" are the tools he meant.
[flagged]
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.
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.
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.
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.
The practice was there before the spec
Which the parent poster said in their comment?
Since it separates out the pathspec, doesn't that match the long standing convention?
The convention is that a leading `-` isn't recognized as a flag after `--`.
Yes, doesn't that match git's behavior? Or are you saying that's not the case?
Why would `--end-of-options` be needed if `--` always signals the end of options? Please read the article.
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.
When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
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:
but: 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.
Flags for Unix tools have never been friendly.
Find is a great example. It's such a useful and powerful tool but it's arguments get me on a regular basis.
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
Yeah, now the LLMs are guessing the commands...
Spot on. I had my repo messed up more than once. Sometimes it is quick enough to push that to GitHub.
So I should name my next branch ‘--‘ is what I'm hearing :)
Name it `-->result.txt`
[flagged]
That's still the default in my localhost, but I get a warning that it'll change.
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.
[flagged]
Why?
There are advantages beyond avoiding the use of a charged term.
It wasn't a charged term and there are not.
there are no advantages, and the massive disadvantage of having to try both every time you encounter a new repository or forget which one it is.
such as?
More meaningful name, shorter to type.
to be fair, I like typing less, and main is shorter than master.
[flagged]
It wasn't anyways. It was clearly in reference to "master copy", which is also not a charged term. Neither was "master bedroom". Hell, for most of my life I'd never even seen anyone raise objections over the master/slave dichotomy used in software and hardware either, which is a far easier to understand argument. It's all very recent, last decade and some change, despite many of these terms having come into use after the abolishment of slavery in the U.S.
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.
> It is literally, the absence of a desire to participate.
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.
My desire to not participate does not mean that I don't want to ever talk about it or that I am trying to minimize time wasted arguing about it. Hell, I'm happy to waste time arguing about anything, really. Especially if it's something that annoys me.
What if someone asked you the same about a new repo?
> I have no reason or desire to change my default branch name
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".
But I do have an issue with you preferring `main`. It means I have the constant annoyance of remembering whether a project uses `main` or `master`.
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.
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.
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 attacker has access to your git??? You’re fucked. Give up.
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.
> 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
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.
You could use an illegal file name symbol as the Options Introducer?
Then you have to have an illegal filename symbol.
Those already exist?
It's really hard to start POSIX options with a NUL byte.
The only way out is malleable software. Have the core data structures and algorithms in a native library. Have a layer of JavaScript/Lua/LISP on top of that. Editable, customizable, reusable.
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.
JJ's use of the Git file format is done via https://github.com/GitoxideLabs/gitoxide -- there's still some missing features in the networking part, but the local-file-manipulation features are fully there.
Great lib. I meant libdog, a different thing. gitoxide is like "git implemented in Rust" while libdog is "git's necessary primitives in C" (objects, packs, sync proto, own index format, diff/merge, etc). As a result, gitoxide is 270KLoC while libdog is 24KLoC, plus 44KLoC of tokenizers. libdog uses token-level algorithms for diff, merge, blame. It also does syntax highlighting in the pager - they all need grammars.
It's from 2019, so it's hardly a recent development.
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?
“Surprised” is not the emotion I would describe when discovering yet another legacy of the insufferable verbosity of EMACS Lisp that the insufferably verbose Stallman loved to spell everything out and create insufferable “new standards” because his autocomplete environment was insufferably superior to everyone else.
Well it's a problem that's existed since day one
why does someone have a filename beginning with a dash?
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.
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?
Access to a well-established set of tools for operating on unstructured text (coreutils, grep, sed, awk, etc.).
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
Master Git and a novice were walking to the market to collect alms.
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:
Postgre, long weary of Master's wisdoms, took a weight of three from the nameless shelf and cut it unevenly. The whole piece he pressed into the novice's bowl; the larger part, he kept for himself.Next stood a shop kept by a bright newcomer, Duck D'Bee.
Master Git repeated:
Duck D'Bee smiled, carefully took an unnamed jar from a vertical stack and handed over one piece and half of another.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:
Silence was the reply. At this point the novice became enlightened.> 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/
The Unix-y world has been around for decades, so it many ways it has evolved rather than be designed.
Yes, the lack of good design in that world is apparent and will continue to cripple a few more generations (but re. evolution that's often a false reading - in many cases it's some primitive napkin design made at the beginning of those decades that stuck without much evolution), but you've wandered into the wrong thread - it's not about the single best format that could've been, just about a circular logic flaw in the argument
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.
Long-term compatibility and the avoidance of vendor lock-in.
How can text enable compabitility if you can't be certain how to parse it, and the rules can change any time??? Similarly with vendors - how can they lock you into themselves if you use some widespread open format?
The point is that every byte of it still means something to you even if you can't "parse" it.
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.
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.
Perhaps I'm missing something (it's been a long day), but couldn't "--" be used for both?
would be the fully specified revspec and pathspec would be just the revspec, excluding accidental options, without a pathspec 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.
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:
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.
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".
Add in "--" a third time, and it's a file in the path spec, like it is for tools like rm.
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,"
> 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)
I don't think you need object orientation for that. Haskell and Rust solve these problems also just fine, without any OOP in sight.
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
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.
> 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
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!
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.
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.
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!
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.
Double dash -> emdash is a default autoreplacement in OSX. That's why a lot of people think it's the default everywhere.
LibreOffice is the same, double hyphen is en-dash and to get an em-dash you have to type:
I thought this was part of why it became an LLM signifier, most people can't tell the difference between the two visually and as far as I knew en-dash is what you usually get by accident, while LLMs use em-dash.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?
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...
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.
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).
because the double hyphen is a convention or placeholder for an emdash
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").
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 sorry, you've learned what now?
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]
[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.
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
Absolute another level of lazy if you need an LLM to git for you.