Earlier quoted context omitted.
There are advantages beyond avoiding the use of a charged term.
such as?
More meaningful name, shorter to type.
git's –end-of-options Flag
71–80 of 133 posts
Re: git's –end-of-options Flag
#72Earlier quoted context omitted.
[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…
> 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".
Re: git's –end-of-options Flag
#73As 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.
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?
Re: git's –end-of-options Flag
#74Earlier quoted context omitted.
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!
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...
Re: git's –end-of-options Flag
#75Earlier quoted context omitted.
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…
> 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 hes…
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.
Re: git's –end-of-options Flag
#76Earlier quoted context omitted.
git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/
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.
Re: git's –end-of-options Flag
#77Does 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!
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.
Re: git's –end-of-options Flag
#78This 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.
Re: git's –end-of-options Flag
#79[deleted]
Re: git's –end-of-options Flag
#80Does 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/
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.