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, among many others, a file "App/android/AndroidManifest.xml"

2. git mv App/android/AndroidManifest.xml App/android/AndroidManifestTemplate.xml

This gives the error message:

fatal: not under version control, source=App/And..."

Initially I thought this might be a gitignore thing, but that's not it either. I tried git fsck, it doesn't report anything.

Any suggestions on how to repair it?

Answer 1

Although my answer won't solve the problem initially raised, it might help someone at some point because I just solved the same problem in a Business Central project...

I was getting this error without being able to avoid it until I realized that I had used an accented vowel in the name of the folder containing the file...

\app\Planificación

After cleanly cloning the project back to another location and copying the contents of that new folder WITHOUT the accented vowel the problem is completely gone.

\app\Planificacion

Hope this can help someone...

Answer 2

Observe if the stage is signed as UNTRACKED (git status). Add the file (git add name_of_file.ext) and then try change again.

Answer 3

Got into this problem today. In my case it seems to be backslashes in the path that cause this issue.

I was trying to rename my file in cmd like this:

cd C:\Path\To\My\File
git mv file1.js file1.ts

This gave me this Not under version control error.

As soon as I switched to git bash instead of cmd and started to use linux-like forward slashed it worked fine.

Answer 4

Most easiest way to solve this issue is to first we need to add the file first and then we need to rename the file

$ git add file-name

$ git mv current-file-name new-file-name

and then your problem will be solve.

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.

Answer 6

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 7

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 8

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 9

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!