0

Why is github showing duplicated files but on my local machine it doesn't show that. I checked by pulling from my main branch in my local machine but it shows that its 'Already up to date.' How do i fix this? The lower case files in my github are old files

enter image description here

enter image description here

  • As I understand you don't want lowercase file in your repo than just got to lowercase 'home' delete every file in it that will automatically delete 'home' also – SidPro Dec 12 '20 at 06:26
  • 1
    It looks like your local machine is a Mac? Files and directories on OSX and MacOS 11 HFS+ and APFS are case preserving but not case sensitive so `Home` and `home` are the same directory on Mac. Github on the other hand runs on linux where files and directories are case sensitive so `Home` is a different directory from `home`. Windows have the same issue on FAT32 but behaves like Linux with NTFS – slebetman Dec 12 '20 at 06:29
  • @SidPro i dont think thats a good idea. I just did that and now my local machine is wanting to delete my uppercase files as well. after deleting 41 files on github, i think github thinks that the uppercases are also expected to be removed. –  Dec 12 '20 at 06:56
  • @Bpun1p i have visited your github ,everything is seems fine as you expected [link](https://github.com/bpun1p/Mern-FoodCore/tree/Main/client/src/components) – SidPro Dec 12 '20 at 07:42
  • @SidPro but when i pull into my machine, i dont get all the files you see on github, alot of it is missing –  Dec 12 '20 at 07:46

1 Answers1

5

Don't set or clear core.ignorecase manually:1 that's just lying to Git. Git sets this value based on how your computer behaves, by performing a relatively time consuming test at git init or git clone time.

Later, Git reads the value to see how your computer will behave as it creates and deletes various files. It then assumes that your computer will and did behave the way the value says. If your computer actually behaves differently, you can get yourself into trouble.

Given that you are on a Mac, the way to fix this is to create a case-sensitive file system, clone the repository there, fix it there, commit, and push the new commit back to GitHub. The fixed-up commits will have whatever files with whatever case you set up. You can then fetch those commits into the copy of the repository on the other, case-insensitive-but-preserving, file system.

In other words, you just create a new virtual disk (see this answer), format it, and make a new (but temporary) repository there where you can work in a case-sensitive manner. Once you're done with this work and have pushed the commits back, you won't need the virtual disk any more (but you can keep it around: I keep one around on mine).

1There are some very special corner cases where, knowing how Git is using core.ignorecase internally, you can set it "wrong" to accomplish something, then fix it again. But it's better to just leave it alone, really. The only time you should set it is if you've changed your computer's behavior—e.g., if you had a backup that included a .git repository on computer A running OS #1, and you've now switched to computer B running OS #2 and restored the backup. If OS #2 behaves differently, now it's time to change core.ignorecase.

torek
  • 448,244
  • 59
  • 642
  • 775