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 111 points 7 months ago (24 children)

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.

[–] BatmanAoD@programming.dev 4 points 7 months ago* (last edited 7 months 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.

load more comments (23 replies)