- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
Whenever I develop on Windows, I just use the built in Linux.
I got a Mac at work because the Linux on Mac didn’t suck as much as the Linux on windows (docker).
My 8 years old mid range PC beats both to dust on development using the Linux on Linux, but somehow the bosses don’t value my time.
The “built-in Linux” is a VM.
I’m aware, though there’s some nice integration stuff that means you can run GUI applications and share the file system
Interesting fact WSLv1 was actually not a VM and it was the NT kernel speaking POSIX
Windows has had the ability to flag individual directories as case-sensitive for a few years now. It’s… something, I guess.
Also, why is the website for the original comic crossed out? It wasn’t completely cropped out or hidden like most asshats do, but it wasn’t left alone either. Someone deliberately went out of their way to vandalize it but did it in perhaps the most pointless possible way? I don’t understand people sometimes.
Eh…. I suppose in one sense it’s making it clear that this isn’t the original. But you can still see where the comic came from.
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?
Inside git’s internal plumbing folder, git holds a file with the branch name and all of the references (files and changes) for that branch.
When you make a new branch git will update its internal plumbing checking to see if the new branch already exists, updates its references to the new branch if it doesn’t (all held internally in a case sensitive way). It will then make that new branch file, git has already checked that the case senitive name for the branch doesn’t exist internally, so it should be good to go.
Part of its process is creating that internal branch file… But wait!
Windows doesn’t have case sensitive naming so when it tries to make that new branch file it will overwrite the old one (since it shouldn’t exist by git’s own reference!) All of the files and references for it now get nuked.
Now you’re at best back to wherever that originally named branch came from, at worse your .git folder is properly borked.
I’m probably going to get downvoted to Hell and back, but someone’s gotta say it: that’s a git problem, not Windows.
First of all, I agree that case-insensitive file systems suck. It makes things inconsistent, especially from a development standpoint.
But, everyone has known that Windows (and macOS) use case insensitive file systems. At least for Windows, it always has been that way.
Git was written in Linux, which uses a case sensitive file system. So it’s no surprise that its internals use case insensitive storage. Someone ported it over to Windows, and I’m sure they knew about the file system differences. They could’ve taken that into account for file systems that are case insensitive, but chose not to do anything to safe guard Windows users.
But until the day that somebody fixes Git, everybody who is not using case sensitive file systems needs to care more about how they name things (and make sure their team does too). Because fuck everyone else, right?
You want all applications to explisitly support each individual filesystem? That sounds insane. It is absolutly fair to demand some common ground like posix compliance. And a windows user can like anyone else just mount their git repo area using any other filesystem.
Well … everyone using case insensitive FSs need to worry how they name stuff anyway.
The issue isn’t just a simple oversight. Git includes the file name as part of the tree and commit hash. The hash has security implications. There’s really no way to make the hash support case insensitivity without opening up a multitude of holes there. So there will always be a mismatch, and you can’t just fix it without changing how git works from the ground up.
Of course you can, make it lowercase internally and store the case formatted string for output.
That’d break git repos where files with the same name, but different case exist.
I was talking about branch names, not file names. File duplicates due to case sensitivity aren’t a problem on Windows anyway because those are already enforced by the file system. Unless you have people working on Linux that have multiple files with a similar name but with different casing but those should know better.
“I’m probably going to get downvoted to Hell and back, but someone’s gotta say it: that’s a git problem, not Windows.”
Beware neckbeards with pitchforks.
that’s a git problem, not Windows.
I use Git, and I don’t use Windows. I have no problems. Sounds like… a Windows problem?
Now use Photoshop.
A kernel was released that changed how the hash value got computed for casefolded filenames. (used for better windows compatibility) That kernel then went into production. This unfortunately split some file-systems that supported this into two incompatible versions, breaking the kernel rule 1.
There might now exist file-systems were created/modified with this bug present that the old/fixed kernels can’t understand.
