Unless you work for the committee or for ISO somehow, then I don't think that really follows. C++ and JavaScript were both used in production for decades before they had standards, and the dissolution of the standards committee wouldn't cause compiler vendors to stop developing compilers.
I agree that it's a "cop-out", but the issue it mitigates is not an individual one but a systemic one. We've made it very, very difficult for apps not to rely on environmental conditions that are effectively impossible to control without VMs or containerization. That's bad, but it's not fixable by asking all app developers to make their apps work in every platform and environment, because that's a Herculean task even for a single program. (Just look at all the compatibility work in a codebase that really does work everywhere, such as vim.)
Huh. I had forgotten that git does actually create a file with the branch name. But it doesn't actually screw up the .git folder 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.
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?
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).
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.
Yes, the dialog was changed, as part of this linked issue (and maybe again after that; this whole incident is very old). After reading some of the comments on that issue, I agree with the reasoning with some of the commenters that it would be less surprising for that menu option to behave like git reset --hard and not delete tracked files.
The user clicked an option to "discard" all changes. They then got a very clear pop-up saying that this is destructive and cannot be undone (there's a screenshot in the thread).
Unless you work for the committee or for ISO somehow, then I don't think that really follows. C++ and JavaScript were both used in production for decades before they had standards, and the dissolution of the standards committee wouldn't cause compiler vendors to stop developing compilers.