392
Something something case-insensitive file something... (lemmy.sdf.org)
submitted 1 day ago by cm0002@lemmy.world to c/programmer_humor@programming.dev
41 comments fedilink hide all child comments
top 41 comments
sorted by: hot top controversial new old
[-] pixelscript@lemm.ee 9 points 15 hours ago

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.

The original, if anyone was curious.

[-] KairuByte@lemmy.dbzer0.com 5 points 14 hours ago

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.

[-] AdNecrias@lemmy.pt 1 points 10 hours ago

Thank you for the rabbit hole

[-] 9point6@lemmy.world 39 points 22 hours ago

Whenever I develop on Windows, I just use the built in Linux.

[-] Railcar8095@lemm.ee 12 points 19 hours ago

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.

[-] GreenKnight23@lemmy.world 10 points 16 hours ago

it's not that they don't value your time, it's that they value security compliance checklists over productivity.

in the same boat myself. Told them the same. practicality begged them to allow me to use docker otherwise tasks would balloon from an hour to complete to literal days.

after two weeks of discussion they finally relented. Probably cost the company $50-70k in those two weeks in salaries alone when you include the entire dev team, IT, security, compliance, and mgmt.

it's amazing that this shitshow called capitalism is still functioning.

[-] 9point6@lemmy.world 4 points 19 hours ago

Technically the "Linux on Mac" is Unix based and not Linux, but I agree the dev experience is nicer on my Mac than Windows given the choice. Also rather than docker you can use the WSL stuff on Windows for a much closer to normal Linux dev setup (with a few weird edges).

I end up regularly using all three OSes, so it's helpful you can finally get a serviceable dev environment on any of the common non-mobile OSes now.

[-] Railcar8095@lemm.ee 5 points 18 hours ago

I meant using a linux VM to run docker (With Rancher Desktop).

WSL started eating RAM like if there's was no tomorrow for no reason, even when idle. And considering we had to run memory and cpu intensive tasks, that was a big problem. Several colleges saw the same issue and we all ended up moving to Mac for that reason (well, some of them just because "shiny").

[-] 9point6@lemmy.world 1 points 18 hours ago

Oh yeah, I'd say Windows in general just chomps through RAM, but there has been some times that WSL takes it to chrome-like levels

[-] Michal@programming.dev 4 points 17 hours ago

The "built-in Linux" is a VM.

[-] 9point6@lemmy.world 13 points 17 hours ago

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

[-] xthexder@l.sw0.com 4 points 15 hours ago

And this is why the WSL1 filesystem was so damn slow. WSL2 uses a native ext4 filesystem (usually, you can format it to whatever)

[-] Irelephant@lemm.ee 1 points 15 hours ago

Same, luarocks just does not work properly on windows.

[-] Michal@programming.dev 6 points 17 hours ago

My main struggle on Windows is checking in executable files. I keep forgetting the command whenever i have to add a shell script to the project.

[-] BatmanAoD@programming.dev 69 points 1 day ago

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?

[-] jeansburger@lemmy.world 106 points 1 day ago

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.

[-] dohpaz42@lemmy.world 74 points 1 day ago

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?

[-] tatterdemalion@programming.dev 1 points 1 hour ago

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?

[-] sep@lemmy.world 12 points 20 hours 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.

[-] UnityDevice@startrek.website 17 points 22 hours ago

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 9 points 21 hours ago* (last edited 21 hours ago)

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

[-] aard@kyu.de 8 points 20 hours ago

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

[-] qaz@lemmy.world 2 points 19 hours ago* (last edited 19 hours 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.

[-] KeenFlame@feddit.nu 3 points 21 hours ago

Yes you can

[-] 30p87@feddit.org 9 points 20 hours ago

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

[-] sep@lemmy.world 7 points 20 hours ago

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

[-] 30p87@feddit.org 4 points 18 hours ago

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

[-] Ephera@lemmy.ml 9 points 23 hours 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...

[-] octade@soc.octade.net 7 points 1 day ago

@jeansburger@lemmy.world

"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@programming.dev 4 points 1 day ago

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

[-] dohpaz42@lemmy.world 4 points 1 day ago

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@programming.dev 3 points 16 hours 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@programming.dev 4 points 18 hours ago

Sounds like a feature to me

[-] BatmanAoD@programming.dev 1 points 23 hours 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.

[-] ulterno@programming.dev 2 points 23 hours 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@programming.dev 2 points 1 day ago

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

[-] dohpaz42@lemmy.world 6 points 1 day ago

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

[-] undefined@lemmy.hogru.ch 6 points 22 hours 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.

[-] BatmanAoD@programming.dev 4 points 1 day ago* (last edited 1 day ago)

Huh. I had forgotten that git does actually create a file with the branch name. But it doesn't actually screw up the .git folder or lose your data when you try to do a rename like this; it just rejects the rename unless you also use the "force" option. This has been the case since at least January of 2020. But apparently it actually doesn't always use a local file for branch names, so sometimes there's a problem and sometimes there isn't, which I guess is arguably worse than just having consistently-surprising behavior.

[-] Vince@lemmy.world 35 points 1 day ago

I understand the joke, but I never had to change the name of a branch because of a wrong upper/lower case character. Hell, I don't think I've ever even renamed a branch. Only matters when you create the PR.

[-] someguy@lemmyland.com 5 points 1 day ago

Funny to see this today. I had moved a repo from an old Mac laptop to linux months ago, and git couldn't find the ref to HEAD, because HEAD was pointing to the case insensitive branch name, and it didn't match the case of the branch. Manually edited HEAD to the correct case to fix it. I should probably recreate the repo for good measure..

this post was submitted on 24 Dec 2024
392 points (100.0% liked)

Programmer Humor

19821 readers
739 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
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev