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.
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)
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.
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.
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
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.
20 comments
[ 0.23 ms ] story [ 26.8 ms ] threadRemembering app-specific one-offs is kind of the worst!
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.
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)
By the way, something munched the article title. An endash is incorrect command-line usage. It’s supposed to be a double hyphen.
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.
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.
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
The saddest thing is even ASCII has characters to help with this but since keyboards can't type them nobody used them.
Which seems unfair because what if they have subconsciously regurgitated Claude-speak?
[1] "That’s a real cost,"