Earlier quoted context omitted.
[flagged]
There are advantages beyond avoiding the use of a charged term.
to be fair, I like typing less, and main is shorter than master.
git's –end-of-options Flag
41–50 of 133 posts
Re: git's –end-of-options Flag
#42As 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 iner…
An attacker has access to your git??? You’re fucked. Give up.
Re: git's –end-of-options Flag
#43Copilot 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.
Re: git's –end-of-options Flag
#44Re: git's –end-of-options Flag
#45[dead]
Re: git's –end-of-options Flag
#46Earlier quoted context omitted.
I don't think you need object orientation for that. Haskell and Rust solve these problems also just fine, without any OOP in sight.
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!
Re: git's –end-of-options Flag
#47Re: git's –end-of-options Flag
#48What a mess. Just use jj instead.
Re: git's –end-of-options Flag
#49Does 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!
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.
Re: git's –end-of-options Flag
#50Does 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