14

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?

ouflak
  • 2,458
  • 10
  • 44
  • 49
Doktor Schrott
  • 616
  • 1
  • 7
  • 14

9 Answers9

27

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!

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 2
    Use tab completion to be safe. – poke Oct 15 '14 at 14:56
  • That was a good suggestion, since I'm checking out under Cygwin, but alas that didn't solve it either. No combination of lower/uppercase I tried made it work. – Doktor Schrott Oct 15 '14 at 15:01
  • @user3512600 in that case, is that element really under version control? (as in http://stackoverflow.com/a/5754899/6309) – VonC Oct 15 '14 at 15:03
  • That's the thing, it's not! It gets created during the clone, so clearly it must be part of the repo, but a "git ls-tree HEAD" in the directory right after doesn't list it. – Doktor Schrott Oct 15 '14 at 15:05
  • @user3512600 there must be some content filter driver at work (look for a `.gitattributes` file with a `smudge` directive in it) (as in http://stackoverflow.com/a/20822928/6309) – VonC Oct 15 '14 at 15:09
  • 2
    After all, the upper/lower-case did indeed turn out to be the issue. 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! – Doktor Schrott Oct 15 '14 at 16:41
  • @user3512600 great feedback. I have included your conclusion in the answer for more visibility. – VonC Oct 15 '14 at 17:35
  • I had a similar problem with Git Shell. I was able to upload changes to github for a file but it gave this error. The problem was, I was typing "cd shuffling" when the correct capitalization was Shuffling. So case-insensitive Windows let me go to "shuffling" but case-sensitive git saw "cd shuffling;git mv map.trizbort maps" as wrong because there was no shuffling\map.trizbort, only Shuffling\map.trizbort. This is slightly different from @DoktorSchrott's issue, but it's another way inconsistent case sensitivity can cause confusion. Hope this helps someone. – aschultz Feb 28 '17 at 01:47
6

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.

NibblyPig
  • 51,118
  • 72
  • 200
  • 356
  • Thanks for this. I was trying everything that made sense and I didn't even notice that it was a case situation with the _path_ instead of the filename. – Khale_Kitha Jan 11 '19 at 19:50
2

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. Screenshot for above issue

0

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.

RayLuo
  • 17,257
  • 6
  • 88
  • 73
0

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

typo
  • 88
  • 7
0

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.

0

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.

Mikhail Dudin
  • 459
  • 5
  • 15
0

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

ouflak
  • 2,458
  • 10
  • 44
  • 49
0

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...

JavierFuentes
  • 1,840
  • 18
  • 13