Earlier quoted context omitted.
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!
git's –end-of-options Flag
31–40 of 133 posts
Re: git's –end-of-options Flag
#32Does 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!
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.
Re: git's –end-of-options Flag
#33Re: git's –end-of-options Flag
#34Earlier quoted context omitted.
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!
Re: git's –end-of-options Flag
#35Earlier 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!
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…
Re: git's –end-of-options Flag
#36Re: git's –end-of-options Flag
#37Earlier quoted context omitted.
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
Re: git's –end-of-options Flag
#38Does 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/
Re: git's –end-of-options Flag
#39Does 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!