I think I've told this story before, but several years ago I discovered this stuff for myself.
I had tidied up a script distribution that had been unloved for a while and got a bit out of hand. I'd been working at home on a Debian laptop, and committed my changes back to Subversion - one of which was to gather up and organise some auxiliary files into one neat and tidy directory. Naturally, since the script already had ./bin, ./lib and ./etc, I went with aux.
I came into work after the weekend to find my Windows-based colleagues, who were in the habit of checking out a single working copy of the entire repo, in full panic mode because "Subversion is broken, IT say we might have lost everything"...
I have lost count of the number of times I have checked out a large Java application which hits the 256 character MAX_PATH limit on Windows. Is a huge pain in the ass as checkout from git or whatever usually works fine but when you try and access the 40 deep folder tree Explorer will error on you.
While I have as much disrespect for Windows and MS in general as any web developer who had to deal with IE, I think this issue is a bug in Git.
Windows git executable should be aware of OS limitations and should be able to work around them. Of course, Windows API should also fail to create invalid fs objects, so there's that...
Microsoft provide file system access which is not impacted by MAX_PATH and that is what git is using when it writes to the file system. If anything I think Microsoft should fix Explorer which they kind of have in Windows 10 with the long path option.
I don't know enough about why Microsoft still have the MAX_PATH problem. I am guessing, like most things Microsoft, it is due to legacy compatibility.
An easy way around this is the `subst` command, which lets you map a folder to a drive letter; if it happens frequently, write up a batch/vbs script and put it in the right-click memu. Of course, if you extracted a prank zip file, you may want to find another method, as there's liable to be far longer paths nested in there...
Oh yeah there are plenty of workarounds, just an annoyance when it catches you out. Not much of an issue if you are on Windows 10 as you can enable Microsoft's long path setting. I don't often use Windows these days though so it is even less of an issue :)
Windows is already case insensitive, no? Case insensitive but case preserving (a file named in ALL CAPS will remain ALL CAPS and can be accessed with lowercase letters as well.)
I had tidied up a script distribution that had been unloved for a while and got a bit out of hand. I'd been working at home on a Debian laptop, and committed my changes back to Subversion - one of which was to gather up and organise some auxiliary files into one neat and tidy directory. Naturally, since the script already had ./bin, ./lib and ./etc, I went with aux.
I came into work after the weekend to find my Windows-based colleagues, who were in the habit of checking out a single working copy of the entire repo, in full panic mode because "Subversion is broken, IT say we might have lost everything"...
These days I name aux directories 'etc'.