Protip worth reminding: under no circumstances rename folder or file in git on Windows changing only letter case. Git will distinguish them, Windows will not. It’s reversible, but cumbersome, especially while working in a team.
The symptoms of such problem I stumbled upon are changes in git which you can’t stage. Undoing them helps temporarily – sooner or later the ghost changes appear again. Deleting the local branch and pulling it again helps for a while. It helps to unblock work especially when you can’t pull any changes and thus push them.
Refreshing git cache or removing some files from cache was recommended on StackOverflow but didn’t work for me.
The reason is that it’s not only a local problem. Our remote repository kept two directories: one with a name written with lower caps – let’s say Dir and second with the upper one: DIR. One of them seemed empty on the remote server, the other had some files, but not all we expected.
We’ve agreed to delete from the remote server the directory which was less “popular” on local machines – let’s assume it was DIR.
The second part of the solution was tricking Windows and git to think that Dir and DIR are the same directory on machines where the folder was written in lowercase: Dir. To do that one can change DIR name to DIRTEMP, Dir to DIR and remove DIRTEMP.
The clue is that Windows will only recognize name changes if it contains more than a letter case change, so add a number or text while you perform the mentioned algorithm. Git, as a more linux software, recognizes different letter cases.
It is possible that git will mark some files as deleted while you perform these operations – after all git recognized that the directory no longer exists. It may be unavoidable to commit those changes, but it’s safe – after all you will find them in git history. Don’t try to revert these commits until you establish that one local machine and remote server see only one directory – one with the correct case.
Now you can add missing files again, best from the same local machine. Don’t revert and commit immediately: just revert and check the casing of the directory name.
Now you can push the changes to the remote. Other team members may see that, after pulling, they have some files marked as deleted. In our case it was enough to discard those changes.
As you can see only resolving this problem took some time and coordination of several people. Before, we struggled with discarding the ghost changes until they magically disappeared and pushing changes was possible. None of the solutions found online so far helped us, so I hope that this post will contribute a small piece of knowledge in this are.
Next up: ensuring the same line endings…