I have a repository on a pc with approximate size of 70GB and when I copied it (not clone, just simple copying) to my mac it shows that some files are untracked while they are already tracked.
When I added them, they appeared to be duplicated in the repo objects info but not in the working tree of course. So I made a hard reset to the last commit but the files appeared again as untracked.
How can I solve this problem? (knowing that the repo on the pc is working well)
问问题
124 次
2 回答
7
Don't copy a repository's working directory from computer to computer.
Problem
Your working directory has checked out files in the appropriate line endings. Your Windows machine uses a carriage return and a line feed to indicate a newline, your Mac does not. You should have configured your PC to do line ending conversion in your repository. Copying the files from Windows to Mac introduces files with Windows-style line endings to your Mac, where they don't belong.
Git has decided that your files have unstaged changes[1] because your line ending configuration instructs your clients to keep Unix-style line endings in the repository and to convert to the proper line ending format when checking files out. This means that when you checked the files out on your PC, they were converted to Windows-style line endings. But your Mac expects to not alter line endings for the repository.
So your repository contains files in Unix format, and your Mac has files in Windows format. So when you run git status, Git realizes that the files in the working directory are different than the files in the repository. (differing only in line endings) and tells you the files have unstaged changes.
Other Problems
There are other reasons not to copy a repository from one computer to another. Git detects the behavior of the computer when a repository is created or cloned (via git init or git clone). Data about the system like whether the filesystem is case-sensitive or case-insensitive, and whether the filesystem supports symbolic links is stored in the repository's configuration.
If you were to copy a repository with a working directory from a Windows computer to a Mac, your repository would no longer support symbolic links. From a Mac to a Linux machine and your repository would get very confused because it thinks it's case insensitive.
Finally, even if you are copying a repository on the same type of computer - or even the same computer itself - you can run into problems. Git caches some working directory information in the index. Copying the working directory should invalidate that cache, but some Git clients may (incorrectly) obey the cache after a copy, which would give false information.
Solution
This is one of the few times where you probably really do want to remove your repository and start over. You could remove all the files in your working directory and clean up your configuration. But at this point, it's realistically much easier to just git clone this repository onto your Mac.
Since the repository is large, if you do not want to spend the network traffic overhead, you can simply clone from the existing repository that you copied. (It will ignore both the misconfigured working directory files and the faulty configuration.) For example, if your damaged repository is in badrepo:
git clone badrepo goodrepo
[1]: Terminology: your files have unstaged changes, your files are not untracked. Untracked files are those that are not yet in the repository.
于 2018-04-18T09:38:44.427 回答
-4
Suggestion: Try to compress after compressing into a zip file
于 2018-04-18T08:59:50.243 回答