0

I have two branches in my remote repository.

  • master has a file in a folder myFolder/myFile.
  • my-branch has a pushed commit that renamed myFolder/myFile (camelCase) to myfolder/myFile (flatcase).

I have cloned it into two local repositories in my case-preserving MacOS environment, set ignorecase = true in the .git/config file, and checked out those two branches

  • When I switch between those two branches with the first local repository, the folder is updated correctly with the correct case, either myFolder or myfolder. This local repository is freshly cloned.
  • But somehow, when I switch between the two branches with the second local repository, the folder's case is not updated, it stays the same. This local repository is older and has seen some git operations done prior to this.

How can I find out why those two local repositories behave differently? They both have the exact same .git/config file

How can I fix the second repository so that the folder case gets correctly updated upon switching branch?

J. Doe
  • 85
  • 12
  • Just to get the most obvious points out of the way: 1. you're **sure** that they both live on the same file system (i.e. not just on two devices with the same file system type, but actually inside the same mounted tree)? 2. did you compare `git config -l --local` between the two for any unexpected differences? – Joachim Sauer Apr 06 '23 at 11:12
  • Yes both local repos are on the same computer, and `git config -l --local` didn't bring up differences besides the older local repo having additional branches – J. Doe Apr 06 '23 at 11:27
  • You say you set Git to ignore case. But the documentation of that option tells you that it has to be set correctly and might result in unexpected behavior. As your file system preserves case, why do you set the config to the opposite and thus probably wrong value? – Vampire Apr 10 '23 at 21:29
  • @Vampire If I set it to `ignorecase = false`, then git won't let me switch branch between `master` and `my-branch` as both have different case for the folder, returning error `error: The following untracked working tree files would be overwritten by switch`. If I force the switch with `switch -f` then it will switch, but will detect all files from that folder as untracked as folder case was not updated. Is there another possibility to switch branch and apply the correct case that I am not aware of? – J. Doe Apr 13 '23 at 16:27
  • If you are on a case-sensitive file system and have the `ignorecase` properly set, switching should usually work fine even if just the case of something changed. This in some empty directory for example works perfectly fine: `git init && mkdir myFolder && touch myFolder/myFile && git add myFolder/myFile && git commit-m 1 && git switch -c my-branch && git mv myFolder myfolder && git commit -m 2 && git switch - && git switch -`. – Vampire Apr 14 '23 at 15:07

1 Answers1

0

How can I fix the second repository so that the folder case gets correctly updated upon switching branch?

As a workaround, since a fresh cloned repository behaves as expected, you could:

  • rename the old second repository
  • clone (a third time) the repository in its place
  • add, if needed, the old and renamed second repository as a remote, to import commits done there in the new (third) fresh repository

Note also that you could use multiple working trees per cloned repository, with the git worktree command, which would avoid the all "switch branch/pray the folder is updated correctly".

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Ideally I would hope there is a solution that would allow the old repository to be kept, as these steps will also need to be executed by other people working on the same remote repo, who will face the same situation with their local repos – J. Doe Apr 06 '23 at 11:36
  • @J.Doe I know, those are workarounds, in case nobody else provides you with a better option. – VonC Apr 06 '23 at 11:37
  • @J.Doe Note that the `git worktree` command I mention in the answer allows you to keep the old repository in place. – VonC Apr 13 '23 at 17:16