My point is that the claim in the comic and in other comments that this corrupts your repo or loses work simply isn’t true.

It’s not even actually that bad, at least not since January of 2020: https://stackoverflow.com/a/59687740/1858225

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?

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.

In the universe where the list is sorted, it doesn’t actually matter how long the destruction takes!

Reminds me of quantum-bogosort: randomize the list; check if it is sorted. If it is, you’re done; otherwise, destroy this universe.

I read “happy ___ starts with ___” as stating that happiness was the eventual result of a process that started with ___.