我对你的用例的假设:

您有一个包含文件和目录的现有目录，现在希望将其转换为从其他地方克隆的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

在不更改本地文件的情况下复制数据。现在应该没事了。

我总是推荐第二种更不容易出错的方法。

我怀疑您的Git安装或存储库有问题。

尝试运行:

GIT_TRACE=2 git <command>

看看能不能找到有用的线索。如果这没有帮助，只需使用strace，看看哪里出了问题:

strace git <command>

有几个原因可以解释为什么git status可能会显示不同，而git diff可能不会。

文件的模式(权限位)发生了变化——例如，从777变为700。 换行风格从CRLF (DOS)到LF (UNIX)

要知道发生了什么，最简单的方法是运行git format-patch HEAD^，看看生成的补丁说了什么。

我有一个类似的问题:git diff会显示差异，但git diff <filename>不会。结果是我将LESS设置为一个包含-F(——quit-if-one-screen)的字符串。移除那面旗帜就解决了问题。

我将文件添加到索引中:

git add file_name

然后跑着说:

git diff --cached file_name

你可以在这里看到git diff的描述。

如果你需要撤销你的git添加，那么请参阅这里:我如何在提交前撤销'git add' ?

对我来说，这与文件权限有关。 在我的项目上使用Mac/Linux的人似乎提交了一些具有非默认权限的文件，我的Windows Git客户端未能重现。

我的解决方案是告诉Git忽略文件权限:

git config core.fileMode false

其他见解:如何让Git忽略文件模式(chmod)的更改?

我遇到了同样的问题，描述如下: 如果我输入

$ git diff

Git只是返回到提示符，没有任何错误。

如果我输入

$ git diff <filename>

Git只是返回到提示符，没有任何错误。

最后，通过阅读，我注意到git diff实际上调用mingw64\bin\diff.exe来完成这项工作。

是这样的。我正在运行Windows，并安装了另一个Bash实用程序，它改变了我的路径，因此它不再指向我的mingw64\bin目录。

如果你输入:

git diff

它只是返回到提示符，你可能有这个问题。

由git运行的div .exe位于你的mingw64\bin中 目录

最后，为了解决这个问题，我实际上复制了我的mingw64\bin目录到Git正在寻找的位置。我试过了，还是不行。

然后，我关闭我的Git Bash窗口并再次打开它，去到我的同一个存储库，现在它可以工作了。

简短的回答

运行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 diff文件没有显示任何内容，因为我将文件添加到git索引中，其中部分名称是大写的:GeoJSONContainer.js。

之后，我将其重命名为GeoJsonContainer.js，并停止跟踪更改。git diff GeoJsonContainer.js没有显示任何东西。我必须用强制标志从索引中删除文件，并再次添加文件:

git rm -f GeoJSONContainer.js
git add GeoJSONContainer.js

我又偶然发现了这个问题。但这一次发生的原因不同。 我将文件复制到存储库中以覆盖以前的版本。现在我可以看到文件被修改了，但是diff没有返回diff。

例如，我有一个主页。xaml文件。 在文件资源管理器中，我粘贴了一个新的主页。Xaml文件超过了我当前存储库中的一个。 我在另一台机器上做了这项工作，只是把文件粘贴到这里。

文件显示已修改，但当我运行git diff时，它不会显示更改。

这可能是因为文件中的fileinfo已经更改，Git知道它实际上不是同一个文件。有趣。

您可以看到，当我在文件上运行diff时，它什么也不显示，只是返回提示符。

我有一个问题，其中数百行结束修改了一些程序和git diff列出所有源文件更改。在修复行尾之后，git状态仍然将文件列为已修改。

我可以通过将所有文件添加到索引，然后重新设置索引来修复这个问题。

git add -A
git reset

核心。文件模式设置为false。

我遇到了这个问题。我的情况与rcwxok发布的LESS问题类似。

在我的例子中，我将PAGER环境变量设置为PAGER='less -RSF'。

然而，与前面的答案不同，我不想删除-F选项，因为我显式地把它放在那里，希望防止在less中显示差异，如果它少于一个屏幕。

为了得到想要的结果，我没有删除-F，而是添加了-X: PAGER='less -RSFX'。这既解决了git差异的问题，此外，它防止显示短差异与较少。

正如在前面的回答中已经提到的，这种情况可能是由于行结束问题(CR/LF vs. LF)而出现的。我用这个命令解决了这个问题(在Git 2.22.0版本下):

git add --renormalize .

根据手册:

       --renormalize
           Apply the "clean" process freshly to all tracked files to
           forcibly add them again to the index. This is useful after
           changing core.autocrlf configuration or the text attribute in
           order to correct files added with wrong CRLF/LF line endings.
           This option implies -u.

Git diff -a将所有文件视为文本，它为我工作。

我使用git svn，有一个文件有这个问题。对文件的每个祖先使用ls-tree，我注意到其中一个有两个子文件夹——Submit和Submit。由于我使用的是Windows，所以不能同时签出它们，从而导致了这个问题。

解决方案是直接从TortoiseSVN Repo-browser中删除其中一个，然后运行git svn fetch，然后执行git reset——hard origin/trunk。

博士TL;

行结束问题:

将自专制设置更改为默认true。例如，在Windows上签出Windows风格的行结束符，并在远程Git存储库中提交linux风格的行结束符: Git配置——全局核心。autocrlf真实 在Windows机器上，将存储库中的所有文件更改为Windows样式: unix2dos * * Git添加所有修改过的文件，修改过的文件将会是: Git添加。 git状态

背景

平台:Windows, WSL

我偶尔会遇到这个问题，git状态显示我修改了文件，而git diff显示什么都没有。这很可能是行结束符的问题。

根本原因

我经常遇到这个问题的原因是我在一台Windows机器上工作，并且在WSL中与Git交互。在Linux和Windows设置之间切换很容易导致这种行尾问题。由于操作系统中使用的行结束格式不同:

Windows: \ r \ n OS X / Linux: \n

常见的做法

当你在你的机器上安装Git时，它会要求你选择行结束设置。通常，常见的做法是在远程Git存储库上使用(提交)linux风格的行结束符，并在Windows计算机上检出Windows风格的行结束符。如果您使用默认设置，这就是Git为您做的。

这意味着如果你有一个shell脚本myScript.sh和Bash脚本myScript.sh。在您的存储库中，这些脚本在远程Git存储库中以linux样式的结尾存在，在您的Windows机器上以Windows样式的结尾存在。

我曾经检查shell脚本文件，并使用dos2unix更改脚本行结束，以便在WSL中运行shell脚本。这就是我遇到这个问题的原因。Git一直告诉我对行结束的修改已经更改，并询问是否提交更改。

解决方案

使用默认的行结束设置，如果更改了某些文件的行结束符(如使用dos2unix或dos2unix)，请删除更改。 如果行尾更改已经存在，并且您想要删除它，尝试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.