1

I am having an odd issue with GIT.

I have a git repo for a small project I'm working on. There are no remotes, this is just for my own work. Up until a few days ago, my development didn't even warrant any branches.

I have finally needed to make a branch for some experimental code. When I was done, I simply checked-out the master branch to go back to where I was. And this is where problems started.

There are six files that change between the new branch and the master branch. Every time I switch / checkout either branch (switching between the two) most of those six file names change case.

For example, if the file was supposed to be someCode.py:

  • Sometimes the file name switches to somecode.py (Incorrect)
  • Sometimes the file name switches to someCode.py (Correct)

It doesn't matter which branch I pick, the result is different every time. And which files end up with which CaSe is different every time.

I suspected the GIT plugin for VSCode I was using (GIT Graph) at first, but it also happens with the included GIT GUI, and even happens if I use "git switch" from the command line.

I read about the core.ignorecase setting; it was set to True. I tried setting it to False and the problem persists.

Does anyone have any ideas what's going on? Thank you

Details:

  • GIT 2.30.0.windows.2
  • Windows 10
  • Files are on a mapped network drive
  • File system is NTFS
Maculin
  • 61
  • 8
  • Unbelievably, today I just merged in someone's branch that was over a year old, and I had this very same problem. It manifested slightly differently in that the first thing I noticed was a file with pending changes that I couldn't undo, or reset- it kept coming back as a change with different contents. I used the comment I wrote (2 days ago!) to diagnose the issue and it exactly pinpointed the cause. I just incorporated that into my answer, as I've now confirmed it happens in real life... – TTT Jan 21 '21 at 21:21

2 Answers2

0

Natively, Git is case sensitive so you could have two different files named filename.txt and FileName.txt. On some operating systems (e.g. Linux) that works fine, and on others (Windows) it does not. Note the same thing goes for branch names too; you can't have two different branches differing by case only on Windows. The reason for this is branch names are stored as a file on your drive.

Most likely your problem is that the files in question have different names on the two branches, but differ by case only. If so, pick which one you want (perhaps master), and on the other branch rename those files to match the casing exactly. If they are actually supposed to be different files, then change their name by more than just casing.

Another possibility is that two (or more) files with names differing by case only exist in the same branch, and switching branches simply causes the issue to come to light. Note it could be the files themselves, or it can be any of the directories in the path to those files could have different casing too. To determine whether this is the problem, navigate to the root of your repo in Git Bash and run this command:

git ls-tree -r HEAD | grep -i [filename-without-path]

If you see two or more files with the same name but different casing, you've identified the problem.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • Thanks for your suggestion. However, to use your example, the files were never called "filename.txt". In fact, the branch only involved some (minor) code changes. There were no files added, removed, or renamed. – Maculin Jan 19 '21 at 16:43
  • You can look at your repo on the `master` branch to see what it thinks the filenames should be. Then you can look at the files on the drive (perhaps with a different tool or even a different machine) to see what the filenames actually are. I suspect they are different. – TTT Jan 19 '21 at 16:46
  • And, since it's a shared drive- could someone/something else be renaming them? – TTT Jan 19 '21 at 16:48
  • Not sure what you mean by "look at your repo on the master branch to see what it thinks the filenames should be". I'm not super familiar with GIT on command line. However, I can use the _Browse master's Files_ option in GIT GUI. It shows the filenames as I expect them, with the correct fileCase. Using Windows Explorer, or the file browser in VSCode, or a command prompt show the file names as whatever they decided to be this time around. And the share drive is from a private server, so no one else would be changing files. – Maculin Jan 19 '21 at 16:59
  • OK. It sounds like the Git repo and your desired names match up. Can you rename them outside of Git to match what you want them to be? After that, do `git status` to make sure Git doesn't think their names should change (it should show no changes if you didn't change anything else). Now see if it still changes when you switch branches. – TTT Jan 19 '21 at 17:09
  • Your analysis of the problem is correct - the file names in the two branches have different cases - but renaming outside of git will have no effect on a case insensitive filesystem (when `core.ignorecase` is set). Instead, use `git mv` on the branch that has the wrong case to correct it. This will rename the filename on-disk and stage the case-changing rename. – Edward Thomson Jan 19 '21 at 17:34
  • @EdwardThomson OP seems to think the two branches don't have different names for those files (which is hard to believe). My last comment is simply to prove that or not. If after making the files match what Git says they are, they either won't change any more (problem solved), or they still do when switching branches, which means we can then isolate which commits on `other-branch` caused the rename. (Or do `git mv` as you suggest to fix it on the other branch.) – TTT Jan 19 '21 at 18:00
  • @TTT: I renamed the file to the correctCase, and ran "git status". Only messages were about some untracked files (I know about those). Switching branches again caused the case to change to be incorrect. Git Status still says nothing about file name changes. – Maculin Jan 19 '21 at 18:14
  • @EdwardThomson: As far as I can tell with every output GIT has given me, the file names are all in the correctCase in both branches. – Maculin Jan 19 '21 at 18:19
  • @Maculin The renames are likely in some commits already on your `other-branch`. To prove that you need to look at *all* the commits on your `other-branch` that aren't in `master` to find which commit(s) did the rename. (Diff the two branches to see.) Once you find them, you can either (if your branch is not shared anywhere yet and only you are working on it) interactive rebase your commits in `other-branch` to drop or edit those commits with the rename, or just add a new commit using `git mv` to rename them to what you want them to be. – TTT Jan 19 '21 at 18:31
  • @TTT, I ran `git diff master other-branch`, and it doesn't show anything unexpected. It shows the lines of code I know I changed in -red and +green, with the file name above the changes like --- a/someFile.py +++ b/someFile.py. The file names are in correctCase in both branches. – Maculin Jan 19 '21 at 18:52
  • 2
    @Maculin Interesting that the diffs aren't showing an issue between branches. Maybe the issue is always there, but switching branches simply causes the issue to come to light. Perhaps the repo actually has two (or more!) copies of those files in it (even on one branch). Note it could be the files themselves, or it can be any of the directories in the path to those files could have different casing too. Navigate to the root of your repo in Git Bash and try this: `git ls-tree -r HEAD | grep -i [filename-without-path]`. I'm thinking each of your files will show up twice with different casing. – TTT Jan 19 '21 at 20:47
  • @TTT I have tried your command, very useful. However, it showed only one of each file that is affected by this. And, it showed it in the correctCase. This is quite baffling. – Maculin Jan 20 '21 at 15:55
  • @Maculin can you try removing/saving off any untracked files so `git status` is completely clean, and then try running that command for each of your branches checked out to see if it's any different? – TTT Jan 20 '21 at 16:50
  • @TTT I have removed my untracked files, and switched to each branch, and run ```git status```. All three show ```On branch X nothing to commit, working tree clean``` – Maculin Jan 20 '21 at 18:49
  • @Maculin and the ls-tree command run from each branch doesn't reveal anything abnormal? – TTT Jan 20 '21 at 19:00
  • @TTT, the ```ls-tree``` command you pointed me at earlier only showed me things I was expecting; files only listed once, and in the correctCase. – Maculin Jan 20 '21 at 20:54
  • It just happened to me too. Right after git clone from MINGW CLI. It lowercased a few files randomly that are not like this in origin in this or any branch. Not even affects all files in one folder - only some of them. git version 2.22.0.windows.1 – xmar Jul 19 '21 at 15:24
0

It seems I have resolved the issue - at least to a point.

I created a new branch, manually fixed the file names in Windows Explorer. Now, switching between master and the newBranch does things as expected.

However, if I ever switch to the firstBranch from the question, the issue resurfaces. There seems to be an issue with that branch, and switching in and out of that branch causes the issue.

I still do not have an answer as to why.

EDIT: OK, maybe not. Repo seems to be having this problem again with other branches.

Maculin
  • 61
  • 8