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.

[–] qaz@lemmy.world 7 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Of course you can, make it lowercase internally and store the case formatted string for output.

[–] aard@kyu.de 11 points 2 weeks ago (1 children)

That'd break git repos where files with the same name, but different case exist.

[–] qaz@lemmy.world -4 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

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.

[–] lseif@sopuli.xyz 1 points 2 hours ago

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 ?

[–] KeenFlame@feddit.nu 1 points 2 weeks ago

Yes you can