我看过所有类似的问题。然而，我又检查了一遍，确实发生了一些奇怪的事情。
在一台服务器上(Solaris with Git 1.8.1)，我克隆了Git存储库，然后将. Git文件夹复制到我现有的活动文件中。这很好，我可以跑了
git status
then
git diff [filename]
检查任何不同的文件。
在另一台服务器上(Solaris with Git 1.7.6)，我做的完全相同
git diff [filename]
即使文件内容完全不同，也不会显示任何内容。我还测试了添加一个新文件，提交它，然后编辑。同样的问题，git status显示文件已更改，但git diff没有显示任何内容。如果我下载更改后的文件并在本地运行diff，那么我将得到diff输出。
当前回答
我有一个问题，其中数百行结束修改了一些程序和git diff列出所有源文件更改。在修复行尾之后，git状态仍然将文件列为已修改。
我可以通过将所有文件添加到索引，然后重新设置索引来修复这个问题。
git add -A
git reset
核心。文件模式设置为false。
其他回答
我遇到了这个问题。我的情况与rcwxok发布的LESS问题类似。
在我的例子中，我将PAGER环境变量设置为PAGER='less -RSF'。
然而，与前面的答案不同，我不想删除-F选项，因为我显式地把它放在那里，希望防止在less中显示差异，如果它少于一个屏幕。
为了得到想要的结果，我没有删除-F，而是添加了-X: PAGER='less -RSFX'。这既解决了git差异的问题，此外，它防止显示短差异与较少。
许多其他答案涉及到行尾和核心的差异。autocrlf设置。确实是这样，但我想指出另一个类似的问题:git过滤器。
如果核心。如果selflf =true，那么该行为就像一个git涂抹或清除过滤器，当文本在工作树和索引之间移动时自动处理文本。
类似地，如果你在文件最后一次提交时改变了你的git过滤器设置，它可能会导致git状态的难以捉摸的差异，而这种差异不会在git diff中显示出来。即使git添加了X;git diff——cached——X，取决于配置的过滤器的性质。
This problem happened to me when using nbstripout, a python package that implements git filters that filter out metadata before adding Jupyter notebook files to the index and before diffing them. I resolved it by reverting the filter config settings to how they were before, running git restore on the affected files, and then re-applying the changes to my filter config (because I wanted to keep the new settings long-term). For me, the settings were stored in .git/config under the filter.nbstripout and diff.ipynb sections.
有几个原因可以解释为什么git status可能会显示不同，而git diff可能不会。
文件的模式(权限位)发生了变化——例如，从777变为700。 换行风格从CRLF (DOS)到LF (UNIX)
要知道发生了什么，最简单的方法是运行git format-patch HEAD^，看看生成的补丁说了什么。
简短的回答
运行git add有时会有所帮助。
例子
Git状态显示已更改的文件和Git diff显示什么都没有…
> git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: package.json
no changes added to commit (use "git add" and/or "git commit -a")
> git diff
>
运行git add可以解决不一致的问题。
> git add
> git status
On branch master
nothing to commit, working directory clean
>
我对你的用例的假设:
您有一个包含文件和目录的现有目录，现在希望将其转换为从其他地方克隆的Git存储库，而不需要更改当前目录中的任何数据。
实际上有两种方法。
克隆repo - mv .git - git重置-硬
此方法就是您所做的—将现有存储库克隆到一个空目录中，然后将.git目录移动到目标目录中。为了顺利工作，通常需要运行
git reset --hard
但是，这会改变当前目录中文件的状态。您可以在目录的完整复制/rsync上尝试此操作，并研究有哪些变化。至少之后你应该不再看到git日志和状态之间的差异。
Init新存储库-指向原点
第二种方法不那么麻烦:cd到您的目的地，并用
git init
然后你告诉这个新的存储库，它在其他地方有一个祖先:
git remote add origin original_git_repo_path
然后安全
git fetch origin master
在不更改本地文件的情况下复制数据。现在应该没事了。
我总是推荐第二种更不容易出错的方法。
