Git 克隆导致已删除和未跟踪的文件

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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 .

Answer 5

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

Answer 6

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.

Answer 7

也可以是文件名中的不可见字符，请在其他系统上查看 ;)

Answer 8

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

Answer 9

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