And the case-sensitivity stuff is somewhat low-hanging fruit, but...

   On Windows, certain path components that are different from ".git"
   are mapped to ".git", e.g. "git~1/config" is treated as if it were
   ".git/config".  HFS+ has a similar issue, where certain unicode
   codepoints are ignored, e.g. ".g\u200cit/config" is treated as if
   it were ".git/config"

So that's what ridiculous means. Huh.

Oh my lord. That's just Windows being vulnerable, rather than git though, right? No way every piece of Windows software protects adequately against that ... misfeature.

There's been half a dozen path traversing exploits against MS IIS, before they finally caved in and took reasonably complete measures in IIS 6 (IIRC).

Nah. From a purist POV, you can sneer at this and say "Bah! Case-insensitive filesystems in 201X? I save `CAT` and that replaces `cat`? Save me, mighty failcats! Wherever else in CS do we accept such blatant approximations, instead of The One And Actual True Computational Result". And you would be mostly right (except for anything floating point).

The reality check is that neither Windows nor MacOS ambushed anyone with overnight with case-insensitivity. It's been there (as the default, right?), since "forever". Git officially supports Win & Mac. Git design already protected .git/config, just not in a sufficiently effective manner (as far as 2/3ds of their major distribution platforms are concerned - yes, the defaults are what you should assume everyone has). [1]

Fun estimate: A lot of technical/knowledgable MacOSX folks, especially in the Webdev/webdesign/etc industries, will have been vulnerable to this despite their personal preferences. Adobe Photoshop (and the others of the creative suite, I think) had a certain idiosyncratic behaviour[2] when certain conditions were not met[3]. You paid thousands for that broken installer/support and Richard Stallman weeps for you.

[1] Aside: You think Git is getting shafted by Windows/Mac implementation idiosyncrasies in this case? Then you'll love the favourite issue node.js on windows: "Breaks on large projects". This is essentially a side-effect of solving the dependency hell problem effectively - by nesting dependencies under a node_modules directory on both project and dependency levels - and insufficient intelligence to foresee that preserving path length is a viable goal in software design (in 200X, no less). Because, in sufficiently bloated projects, you can have enough nested node_modules/$name/node_..., that you literally blow Windows' fuse. But it's not a big deal, because that max path length is like some huge number, like 2^32 or some shit. Righ - 260 characters. 257 and C:\. Including slashes and all. So when node.js picked the completely reasonable "node_modules" as a dependency includes dir name, they should have known better - that their project would attract a huge audience and that sufficiently complicated/bloated packages would be created and distributed that their depencency-includes-dir-name selection would become a show-stopper, because one of our favourite OSes is still eating glue in the corner. And what didn't actually work? Not node. Not npm. Windows Explorer and other tools/utils that weren't updated to support NTFS' actual maximum path size - 32K. On the one hand, node.js github issues piling up ("FIXITTT!!!!") and on the other, Microsoft says "NTFS supporting 32K path length, while Windows Explorer supporting 260 chars, is not a bug. Repeat, not a bug."

[2] Didn't work at all. "It isn't a bug, it's a System Requirement."

[3] Case-insensitivity in the FS. Not just as a concept, but as a pre-requisite for installing an expensive class-A consumer design application. Really think about this. You've just paid between 3 and 4 digit sums for this single license. The installer creates a bunch of files, but for securitah(?) we randomize capitalization of all paths (!) so the only way this could possibly work is if the god damned filesystem is cool with the app sometimes requesting 'Data', others 'data', occasiionally (during rants, mostly) 'DATA', and every April Fools day, 'dAtA', and always getting back the (proper) 'daTA'. As a developer, isn't this about as desirable as trying to save "C:\programs I should delete.txt" and receiving a "C:\progra~2.txt" path in return? What the unholy fuck? I asked for a very specfic filename. Either error me outta here ('Sorry Dave, I can't do space') or do exactly as I said.

[4] No, you're drun.