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.
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.
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.
so now its the Linux users who should know better, just in case git introduces a breaking change out of nowhere ?
…but not the ones using a case-insensitive file system with case-sensitive version control ?
Yes you can