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:
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.
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
.
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/MyV
Tab 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 dir
Tab will automatically fix that incorrect case for you and you will get git mv Dir/
. Keep using Tab for each part of your path.