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.
> The name is verbose, but that's probably a good thing; this is meant to
be used for scripted invocations where readability is more important
than terseness.
That reasoning makes sense to me. In over a decade of using git, I've never had a case where I'd need to disambiguate a ref that could be confused as an option. And if I did I'd know the ref name so I'd use its full path: `refs/head/--whatever` (just like with `rm` where I prefer `rm ./--whatever` over `rm -- --whatever`).
So yes, this is oddly named, but it was retrofitted so options were limited and it's fine for its intended use case.
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.
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.
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/
Since it separates out the pathspec, doesn't that match the long standing convention?
When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
So I should name my next branch ‘--‘ is what I'm hearing :)
just don't call it master
That's still the default in my localhost, but I get a warning that it'll change.
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.
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.
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.
From the commit[^1]:
> The name is verbose, but that's probably a good thing; this is meant to be used for scripted invocations where readability is more important than terseness.
That reasoning makes sense to me. In over a decade of using git, I've never had a case where I'd need to disambiguate a ref that could be confused as an option. And if I did I'd know the ref name so I'd use its full path: `refs/head/--whatever` (just like with `rm` where I prefer `rm ./--whatever` over `rm -- --whatever`).
So yes, this is oddly named, but it was retrofitted so options were limited and it's fine for its intended use case.
[^1]: https://github.com/git/git/commit/19e8789b236dfe33667747d552...
> 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.
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.
I'm sure I typed double-hyphen when submitting the post, but probably HN auto-formatted the title. IDK really.
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?
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