I honestly don't even understand the joke. Case-insensitive file names cause problems, but what does that have to do with version control branch names?
BatmanAoD
joined 2 years ago
Yeah, consistency is good, which is why it's good to follow the spec. I'm saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.
The spec requires errors to be a single string, and also mandates using the space character as a separator? I'm not a fan of deviating from spec, but those are...bad choices in the spec.
For anyone else wondering, here's the text of the actual email cited as the CoC violation:
Michal, if you think crashing processes is an acceptable alternative to error handling you have no business writing kernel code.
You have been stridently arguing for one bad idea after another, and it's an insult to those of us who do give a shit about writing reliable software.
You're arguing against basic precepts of kernel programming.
Get your head examined. And get the fuck out of here with this shit.
I agree, but if you look at the specific email linked, it very clearly crosses the line into direct abuse, whereas most of Linus's rants do exist in a slightly greyer area (even if they'd be grounds for a discussion with HR at an actual company).
the function reads the comment added after the function is called using a backtrace and uses them as arguments
How marvelously creative. What an abomination.
The second button is actually a pretty major change!
It means both.
It had a reasonably clear warning, though; a screenshot is included in this response from the devs. But note that the response also links to another issue where some bikeshedding on the warning occurred and the warning was ultimately improved.
In reality, that was added four and a half years after this issue was opened.
Huh. I had forgotten that git does actually create a file with the branch name. But it doesn't actually screw up the
.gitfolder or lose your data when you try to do a rename like this; it just rejects the rename unless you also use the "force" option. This has been the case since at least January of 2020. But apparently it actually doesn't always use a local file for branch names, so sometimes there's a problem and sometimes there isn't, which I guess is arguably worse than just having consistently-surprising behavior.