git says “not under version control” for just-checked-out file

Question

I have the distinct impression my Git repo is somehow mangled.

Here\'s the sequence I\'m doing:

1. git clone [remote\'s clone string]

   This creates,

Answer 1

Maybe App/android/AndroidManifest.xml does exist, but with a diferent case (like App/android/androidmanifest.xml, which would mean that App/android/AndroidManifest.xml isn't versioned (hence the error message):

Doing the git mv with the right case should then be enough.

The OP explains in the comments:

What happened was that there were two folders in Git, "App" and "app".
When I checked out the repo under Windows, because of the case-insensitivity of Windows, it actually overlayed the two folders into one into "App".
Which meant, the directory structure was fine, but half of the files (the ones coming from the "app" side) had an invalid Git path!

Answer 2

All the answers above are great, I found this when trying to move files, and Capitalize them during the same commit

By committing my new file path, I could access the new path and then git mv (:

problem solved

Answer 3

Another quirk that left me frustrated is if you're using the command line, it will use your current path to git mv the file. So if you have a file in C:\Git\MyRepo\MyFolder\MyFile.txt

If you do:

c:

cd git

cd myrepo

cd myfolder

dir

It will work fine, you'll see your file. But if you type git mv MyFile.txt MyFile2.txt you will get an error because git can't find Myfile.txt.

The reason is that it's looking at your current path, which is c:\git\myrepo\myfolder\

But git is case sensitive. So you have to go back and type

c:

cd Git

cd MyRepo

cd MyFolder

If you then type git mv it will work fine.

Putting this in as an answer for people like me that found this post while debugging this error message.

Answer 4

The situation encountered by the OP, as described in the currently chosen answer, is caused by 2 pre-existing folders (or file names, for that matter) have same spelling but different case. That was a bad naming choice in the first place, and hopefully won't happen very often.

Here, for the sake of completeness, the same "not under version control" error message can also happen when using git bash on Windows, when you did not specify the old file name with precise correct case.

Example:

1. Assuming there is a file path contains mixed case Dir/MyVeryLongFileName.txt in your repo, and git will store its file path in a case-sensitive way.

2. Now you type git mv dir/MyV Tab. Let's say you did not use TAB auto-completion for the path dir, probably because it is short enough to type, and you did not notice that you incorrectly typed its first letter as d rather than D.

3. Since Windows is case-insensitive, the TAB auto-completion would still work, so you now have this in the command-line

   $ git mv dir/MyVeryLongFileName.txt
   

   Now you go ahead to finish your command, and, BOOM, you get the error:

   $ git mv dir/MyVeryLongFileName.txt somewhere/else/
   fatal: not under version control, source=dir/MyVeryLongFileName.txt, destination=somewhere/else/MyVeryLongFileName.txt
   

   In fact, if you use the same style to type ls dir/MyVTab for your investigation, the bash will tell you that old file exists (despite its actually wrong case spelling), which is misleading.

All these above are not rocket science, but it woudl be tricky enough to raise your blood pressure when you were racing with time to get your PR ready. #LearnInTheHardWay

The moral of the story? Use TAB auto-completion even after you already type a dir name. In the example above, typing git mv dirTab will automatically fix that incorrect case for you and you will get git mv Dir/. Keep using Tab for each part of your path.

Answer 5

Since git is case sensitive, but the OS is not, git thinks the path is wrong when it actually exists with different caps.

A programmatic way to fix this can be deleting the conflicting path from the OS and then doing a git reset --hard HEAD or checkout the directory from the HEAD.