this post was submitted on 24 Dec 2024
439 points (95.4% liked)

Programmer Humor

19829 readers
533 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 68 points 2 days ago (9 children)

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?

[–] [email protected] 16 points 2 days ago (2 children)

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.

[–] [email protected] 8 points 2 days ago* (last edited 2 days ago) (1 children)

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

[–] [email protected] 9 points 2 days ago (1 children)

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

[–] [email protected] -2 points 2 days ago* (last edited 2 days ago)

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.

[–] [email protected] 0 points 2 days ago
[–] [email protected] 8 points 2 days ago (1 children)

Well ... everyone using case insensitive FSs need to worry how they name stuff anyway.

[–] [email protected] 7 points 2 days ago (1 children)

Absolutly. And they can just mount the git store using another filesystem. Would be the by far easiest solution.

[–] [email protected] 4 points 2 days ago (1 children)

Or use OS's where case sensitive FS's are the default. The ones I have in mind are much better for programming anyway...

[–] [email protected] 2 points 1 day ago

Well obviously. But I assume they would not use windows unless they are forced to.

[–] [email protected] 8 points 2 days ago

I agree that the meme is silly to point to this problem specifically. However, if we leave aside application support as a reason to prefer an OS, then there is really not a lot of arguments left for choosing Windows...

[–] [email protected] 6 points 2 days ago

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.

[–] [email protected] 8 points 2 days ago

@[email protected]

"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.

[–] BatmanAoD 5 points 2 days ago (1 children)

It's not even actually that bad, at least not since January of 2020: https://stackoverflow.com/a/59687740/1858225

[–] [email protected] 3 points 2 days ago (3 children)

That’s called a workaround. No end user should have to rely on a workaround as a solution to a bug; and make no mistake, it’s a bug.

[–] anzo 4 points 2 days ago

But whose bug is it? Really, Git origins have it tied to Linux development.

Case sensitivity, or the lack thereof, on a filesystem is opinionated. That's the real issue and is not a bug.

[–] Scoopta 4 points 2 days ago

Sounds like a feature to me

[–] BatmanAoD 2 points 2 days ago

My point is that the claim in the comic and in other comments that this corrupts your repo or loses work simply isn't true.

[–] tatterdemalion -1 points 1 day ago (1 children)

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?

[–] [email protected] 1 points 22 hours ago

Now use Photoshop.

[–] ulterno 3 points 2 days ago

Also, if you use an NTFS USB drive to move the .git folder, you will be in trouble.
Thankfully, moving those things to pen drives is very slow, making most users tar it first, anyway, hence sidestepping the problem.

[–] eluvatar 2 points 2 days ago (1 children)

Does Mac suffer the same bugs as windows in this case?

[–] [email protected] 6 points 2 days ago (1 children)

Yes. Thankfully in my experience I’ve only dealt with this once or twice. But it’s a pita every time.

I’ve tried switching macOS to a case sensitive file system, but not all programs can handle it (at the time it was Photoshop).

[–] [email protected] 6 points 2 days ago

I never understood this. I’ve been using macOS for a long, long time but in Terminal with either bash or zsh it’s always been as picky as Linux/other UNIX systems with casing.

Even in Finder if you navigate to a directory by path you have to use the proper case.

Am I missing something? I haven’t manually chosen a case-sensitive filesystem, but I sure would if it didn’t already seem case-sensitive.