26

I am new to Git.

I just installed Git (2.9.3) for Windows (10), then I opened git-bash and did a git clone <remoteURL>. A new folder is created with the whole copy of the remote repository, which is good. But then I run a git status and I get a ton of deleted files (I suppose all the files that just got copied) ready to be committed, and the three main folders under the repository folder are untracked. The deleted files actually exist on my drive though!

I am pretty sure my git status should be clean instead. What is happening?

This about deleted files didn't help (I didn't use checkout), neither did this about untracked files (I'm not using Mac OS).

Community
  • 1
  • 1
pHneutre
  • 1,091
  • 3
  • 12
  • 29

10 Answers10

36

I was retrieving a huge project with very long paths. I forgot to set up Git to use long paths:

git config --global core.longpaths true

After this, the cloning went fine and the status clean.

pHneutre
  • 1,091
  • 3
  • 12
  • 29
11

It sounds like you've somehow loaded an empty index. The normal way this happens in with the command git read-tree --empty, but that's not something you usually use/know as a new user of git.

Perhaps something went wrong with the clone. It's shouldn't be difficult to fix though, just run

git reset

and the index should be restored to the contents of the latest commit.

Per Johansson
  • 6,697
  • 27
  • 34
  • The reset lead me on the right way: only deleted files remaining were actually absent on my drive, and they probably had the longest paths. See my answer. – pHneutre Aug 17 '16 at 08:59
  • 1
    `git reset` fixed it for me. Thanks! – TheTechGuy Mar 26 '18 at 11:01
  • git reset worked for me to, a lot of answers about this where about different line endings, which apparently had nothing to do with it! – Cerveser Jun 02 '23 at 21:46
7

This issue confuses not only the OP who "is new to git". It also scares the sh*t out of me, a considerable git verteran. :-)

Thanks for the hints from other answers here, I realize that it is caused by git happens to be NOT able to checkout some files whose names contains unsupported characters on current file system and/or OS. For example, I encountered this same error when I'm cloning a github wiki repo, some wiki pages happen to contain a : in its file name, they can be cloned fine on my Linux box, but (at a hindsight) obviously not on my Windows box.

Understanding the root cause gives us a confident decision on how/whether we fix this problem:

  • We can fix it in the repo by renaming those offending filenames into shorter and/or containing only usual alphabet.
  • Or, technically we do NOT have to fix it at all. If those offending filenames were just fine on their targetting platform, and we are working on some other content of this repo, we can continue our work as usual; we just need to remember to NOT commit those missing files as a deletion. (Been there, done that; Don't try this at home.)
RayLuo
  • 17,257
  • 6
  • 88
  • 73
  • 1
    A 'git reset' pointed me to a file with spaces and a colon : in it. Deleting the file solved the problem. This should be the accepted answer. – Robyc Apr 07 '20 at 16:39
  • I should add that I used the same repository on Linux and Mac without problems. git version on windows (where the problem appeared) is 2.26.0.windows.1 – Robyc Apr 07 '20 at 16:41
3

If you experience problems on Windows might check your file names against these forbidden characters:

< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

Or files named with one of the reserved words below or one of these immediately followed by the extension: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.

More details can be found here.

Yaroslav Yakovlev
  • 6,303
  • 6
  • 39
  • 59
2

In case you end up here and the longpath property did not work AND you run on Windows and use Git Bash you might have files using reserved keywords in Windows. Ie, I had files with nulin it, and those got deleted after clone. I spent half a day finding it was this reserved keyword thing.

The solution for that is simply renaming the file (on your other machine / OS where you could create it). Push it, and then redo the clone operation on your Windows machine.

Stefan Hendriks
  • 4,705
  • 5
  • 34
  • 43
1

In my case, I had cloned the repo in a case insensitive filesystem on my Mac, however the repo included a file named Config and a directory named config, which the filesystem considered as the same thing. So, upon clone, it displayed that the file Config was deleted.

The fix was to clone the repo on a case sensitive file system.

SerkanC
  • 482
  • 4
  • 4
0

Can be also invisible characters in filenames, check it out on other systems ;)

pkopac
  • 986
  • 1
  • 13
  • 21
0

I faced the similar issue with windows 10 , I checked other windows as well where git was working fine , My git version was 2.24.xx. i installed the git older version of git 2.16.x and it solves the problem. Try it and let know

Manish Sharma
  • 1
0

The behavior which showing some files as modified could be related to line ending setting and multiple client used. Every operating system handles line endings in it's own way. So if you are working on repositry where in the the files are edited in multiple operating systems, you may see unexpected results

The following command will solve the issue permanently

git config --global core.autocrlf input

Suresh Mahalingam
  • 1
  • 1
0

This works for me, and just this comand:

git config --global core.protectNTFS false
Uéslei Suptitz
  • 325
  • 1
  • 7