即使内容相同，Git 状态也会显示文件已更改

Git status shows files as changed even though contents are the same

提问by Aron Rotteveel

I received a git checkout from someone else and am trying to commit the unstaged changes to the local repository. However, a lot(if not every) file appears as modifiedeven though the contents are exactly the same.

我收到了来自其他人的 git checkout 并尝试将未暂存的更改提交到本地存储库。但是，即使内容完全相同，很多（如果不是每个）文件也会显示为已修改。

I already set core.fileModeto false and also set core.autocrlfto false, without success.

我已经设置core.fileMode为false，也设置core.autocrlf为false，但没有成功。

Worth mentioning is that the Git repo I received was from someone using Windows, while I use Linux.

值得一提的是，我收到的 Git 存储库来自使用 Windows 的人，而我使用的是 Linux。

What can I do to commit the actualchanges?

我可以做些什么来提交实际更改？

EDIT: output of git config -l:

编辑：输出git config -l：

user.name=Aron Rotteveel
user.email=<removed>
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=auto
color.ui=true
color.pager=true
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red bold
color.diff.new=green bold
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
core.pager=less -FRSX
core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
alias.co=checkout
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=false
remote.origin.url=<removed>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

Update: added some random example files. These files are just plaintext, so are the easiest to include.

更新：添加了一些随机示例文件。这些文件只是纯文本，因此最容易包含。

Original files are located here: https://gist.github.com/c3c5302430935155ef3d. Hexdumps definately indicate that the files are different, but I have no clue what causes this, and how to fix it.

原始文件位于：https: //gist.github.com/c3c5302430935155ef3d。Hexdumps 肯定表明文件不同，但我不知道是什么原因导致的，以及如何解决它。

HEAD version:

头版：

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740d  HTML.SafeObject.
0000010: 0a54 5950 453a 2062 6f6f 6c0d 0a56 4552  .TYPE: bool..VER
0000020: 5349 4f4e 3a20 332e 312e 310d 0a44 4546  SION: 3.1.1..DEF
0000030: 4155 4c54 3a20 6661 6c73 650d 0a2d 2d44  AULT: false..--D
0000040: 4553 4352 4950 5449 4f4e 2d2d 0d0a 3c70  ESCRIPTION--..<p
0000050: 3e0d 0a20 2020 2057 6865 7468 6572 206f  >..    Whether o
0000060: 7220 6e6f 7420 746f 2070 6572 6d69 7420  r not to permit 
0000070: 6f62 6a65 6374 2074 6167 7320 696e 2064  object tags in d
0000080: 6f63 756d 656e 7473 2c20 7769 7468 2061  ocuments, with a
0000090: 206e 756d 6265 7220 6f66 2065 7874 7261   number of extra
00000a0: 0d0a 2020 2020 7365 6375 7269 7479 2066  ..    security f
00000b0: 6561 7475 7265 7320 6164 6465 6420 746f  eatures added to
00000c0: 2070 7265 7665 6e74 2073 6372 6970 7420   prevent script 
00000d0: 6578 6563 7574 696f 6e2e 2054 6869 7320  execution. This 
00000e0: 6973 2073 696d 696c 6172 2074 6f0d 0a20  is similar to.. 
00000f0: 2020 2077 6861 7420 7765 6273 6974 6573     what websites
0000100: 206c 696b 6520 4d79 5370 6163 6520 646f   like MySpace do
0000110: 2074 6f20 6f62 6a65 6374 2074 6167 732e   to object tags.
0000120: 2020 596f 7520 7368 6f75 6c64 2061 6c73    You should als
0000130: 6f20 656e 6162 6c65 0d0a 2020 2020 254f  o enable..    %O
0000140: 7574 7075 742e 466c 6173 6843 6f6d 7061  utput.FlashCompa
0000150: 7420 696e 206f 7264 6572 2074 6f20 6765  t in order to ge
0000160: 6e65 7261 7465 2049 6e74 6572 6e65 7420  nerate Internet 
0000170: 4578 706c 6f72 6572 0d0a 2020 2020 636f  Explorer..    co
0000180: 6d70 6174 6962 696c 6974 7920 636f 6465  mpatibility code
0000190: 2066 6f72 2079 6f75 7220 6f62 6a65 6374   for your object
00001a0: 2074 6167 732e 0d0a 3c2f 703e 0d0a 2d2d   tags...</p>..--
00001b0: 2320 7669 6d3a 2065 7420 7377 3d34 2073  # vim: et sw=4 s
00001c0: 7473 3d34 0d0a                           ts=4..

Copied version:

复制版本：

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740a  HTML.SafeObject.
0000010: 5459 5045 3a20 626f 6f6c 0a56 4552 5349  TYPE: bool.VERSI
0000020: 4f4e 3a20 332e 312e 310a 4445 4641 554c  ON: 3.1.1.DEFAUL
0000030: 543a 2066 616c 7365 0a2d 2d44 4553 4352  T: false.--DESCR
0000040: 4950 5449 4f4e 2d2d 0a3c 703e 0a20 2020  IPTION--.<p>.   
0000050: 2057 6865 7468 6572 206f 7220 6e6f 7420   Whether or not 
0000060: 746f 2070 6572 6d69 7420 6f62 6a65 6374  to permit object
0000070: 2074 6167 7320 696e 2064 6f63 756d 656e   tags in documen
0000080: 7473 2c20 7769 7468 2061 206e 756d 6265  ts, with a numbe
0000090: 7220 6f66 2065 7874 7261 0a20 2020 2073  r of extra.    s
00000a0: 6563 7572 6974 7920 6665 6174 7572 6573  ecurity features
00000b0: 2061 6464 6564 2074 6f20 7072 6576 656e   added to preven
00000c0: 7420 7363 7269 7074 2065 7865 6375 7469  t script executi
00000d0: 6f6e 2e20 5468 6973 2069 7320 7369 6d69  on. This is simi
00000e0: 6c61 7220 746f 0a20 2020 2077 6861 7420  lar to.    what 
00000f0: 7765 6273 6974 6573 206c 696b 6520 4d79  websites like My
0000100: 5370 6163 6520 646f 2074 6f20 6f62 6a65  Space do to obje
0000110: 6374 2074 6167 732e 2020 596f 7520 7368  ct tags.  You sh
0000120: 6f75 6c64 2061 6c73 6f20 656e 6162 6c65  ould also enable
0000130: 0a20 2020 2025 4f75 7470 7574 2e46 6c61  .    %Output.Fla
0000140: 7368 436f 6d70 6174 2069 6e20 6f72 6465  shCompat in orde
0000150: 7220 746f 2067 656e 6572 6174 6520 496e  r to generate In
0000160: 7465 726e 6574 2045 7870 6c6f 7265 720a  ternet Explorer.
0000170: 2020 2020 636f 6d70 6174 6962 696c 6974      compatibilit
0000180: 7920 636f 6465 2066 6f72 2079 6f75 7220  y code for your 
0000190: 6f62 6a65 6374 2074 6167 732e 0a3c 2f70  object tags..</p
00001a0: 3e0a 2d2d 2320 7669 6d3a 2065 7420 7377  >.--# vim: et sw
00001b0: 3d34 2073 7473 3d34 0a                   =4 sts=4.

采纳答案by sehe

Update: as per the comment on this question, the problem has been solved:

更新：根据对这个问题的评论，问题已经解决：

That is easy: the first file has CRLF line-ends (windows), the second LF (Unix). The fileutil (available in git\usr\bin) will show you that (file a bwill reply something like a: ASCII text, with CRLF line terminators b: ASCII text)

这很简单：第一个文件有 CRLF 行尾（windows），第二个 LF（Unix）。该fileUTIL（Git中的\ usr \ bin中提供）会告诉你，（file a b将回复类似a: ASCII text, with CRLF line terminators b: ASCII text）

Original answer below:

原答案如下：

---

---

The diff you show does notshow a single different line. Can you post .git/config (or better git config -l).

您显示的差异不显示单个不同的行。你可以发布 .git/config （或更好git config -l）。

You might have some whitespace ignores activated

您可能激活了一些空白忽略

You should try to disable core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

您应该尝试禁用core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

also

还

git show HEAD:myfile|md5sum
md5sum myfile

could be used to verify that the files are in fact different. Using external diff could work as well

可用于验证文件实际上是不同的。使用外部差异也可以

git show HEAD:myfile > /tmp/myfile.HEAD

diff -u myfile /tmp/myfile.HEAD

# or if you prefer an interactive tool like e.g.:
vim -d myfile /tmp/myfile.HEAD

回答by Jacek Szybisz

I have resolved this problem using following stpes

我已经使用以下 stpes 解决了这个问题

1) Remove every file from Git's index.

1) 从 Git 的索引中删除每个文件。

git rm --cached -r .

2) Rewrite the Git index to pick up all the new line endings.

2) 重写 Git 索引以获取所有新行结尾。

git reset --hard

Note that step 2 may remove your local changes. Solution was part of steps described on git site https://help.github.com/articles/dealing-with-line-endings/

请注意，第 2 步可能会删除您的本地更改。解决方案是 git 站点https://help.github.com/articles/dealing-with-line-endings/上描述的步骤的一部分

回答by itsandy

Have you changed the mode of the files? I did it on my machine and the local dev machine had 777 given to all the files whereas the repo had 755 which showed every file as modified. I did git diffand it showed the old mode and new mode are different. If that is the problem then you can easily ignore them by git config core.filemode false
Cheers

您是否更改了文件的模式？我是在我的机器上做的，本地开发机器有 777 个给所有文件，而 repo 有 755 个，显示每个文件都被修改了。我做了git diff，它显示旧模式和新模式是不同的。如果这是问题，那么您可以通过git config core.filemode false
Cheers轻松忽略它们

回答by Demo_S

i had the same problem. after win->lin copy i've got all files modified.
i used fromdosto fix line endings
and then

我有同样的问题。在 win->lin copy 之后，我修改了所有文件。
我用fromdos来修复行尾
，然后

git add -uv 

to add changes.
it added 3 files (not all of them), which i actually modified. and after that git statusshows only 3 modified files. after git commiteverything is ok with git status

添加更改。
它添加了 3 个文件（不是全部），我实际上修改了这些文件。之后git status只显示 3 个修改过的文件。在git commit之后，git status 一切正常

回答by Michael Freidgeim

I was able to fix the problems on Windows machine by changing core.autocrlf from false to core.autocrlf=input

我能够通过将 core.autocrlf 从 false 更改为 core.autocrlf=input 来解决 Windows 机器上的问题

git config core.autocrlf input

as it's suggested in https://stackoverflow.com/a/1112313/52277

正如https://stackoverflow.com/a/1112313/52277 中所建议的那样

回答by VonC

However, a lot (if not every) file appears as modified even though the contents are exactly the same.

但是，即使内容完全相同，很多（如果不是每个）文件也会显示为已修改。

With git 2.8 (March 2016), you will able to quickly check if those changes are eol-related.

使用 git 2.8（2016 年 3 月），您将能够快速检查这些更改是否与 eol 相关。

See commit a7630bd(16 Jan 2016) by Torsten B?gershausen (tboegi).
^{(Merged by Junio C Hamano -- gitster--in commit 05f1539, 03 Feb 2016)}

请参阅Torsten B?gershausen ( )提交的 a7630bd(2016 年 1 月 16 日)。^{（由Junio C Hamano合并-- --在commit 05f1539，2016 年 2 月 3 日）}tboegi
gitster

ls-files: add eol diagnostics

When working in a cross-platform environment, a user may want to check if text files are stored normalized in the repository and if .gitattributesare set appropriately.

Make it possible to let Git show the line endings in the index and in the working tree and the effective text/eol attributes.

The end of line ("eolinfo") are shown like this:

ls-files: 添加 eol 诊断

在跨平台环境中工作时，用户可能想要检查文本文件是否已规范化存储在存储库中以及是否.gitattributes进行了适当设置。

让 Git 在索引和工作树中显示行尾以及有效的 text/eol 属性成为可能。

行尾 (" eolinfo") 显示如下：

"-text"        binary (or with bare CR) file
"none"         text file without any EOL
"lf"           text file with LF
"crlf"         text file with CRLF
"mixed"        text file with mixed line endings.

The effective text/eol attribute is one of these:

有效的 text/eol 属性是其中之一：

"", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf"

git ls-files --eolgives an output like this:

git ls-files --eol给出这样的输出：

i/none   w/none   attr/text=auto      t/t5100/empty
i/-text  w/-text  attr/-text          t/test-binary-2.png
i/lf     w/lf     attr/text eol=lf    t/t5100/rfc2047-info-0007
i/lf     w/crlf   attr/text eol=crlf  doit.bat
i/mixed  w/mixed  attr/               locale/XX.po

to show what eol convention is used in the data in the index ('i'), and in the working tree ('w'), and what attribute is in effect, for each path that is shown.

显示索引 (' i') 和工作树 (' w')中的数据中使用的 eol 约定，以及显示的每个路径的有效属性。

回答by Sakis

In my case the files were appeared as modified after changing the files permissions.

在我的情况下，文件在更改文件权限后显示为已修改。

To make git ignore permission changes, do the following :

要使 git 忽略权限更改，请执行以下操作：

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

回答by truthseeker

Here is how I fixed the problem on Linux while I cloned a project that was created on Windows:

以下是我在克隆在 Windows 上创建的项目时在 Linux 上解决问题的方法：

on linux in order for things to work properly you have to have this setting: core.autocrlf=input

在 linux 上为了让事情正常工作，你必须有这个设置：core.autocrlf=input

this is how to set it: git config --global core.autocrlf input

这是如何设置它： git config --global core.autocrlf input

Then clone the project again from github.

然后再次从github克隆项目。

回答by Mark Longair

The Git FAQhas an answer that might be relevant, although I've never come across this before:

在Git的常见问题有一个答案，可能是相关的，虽然我以前从来没有过这个来：

Why does git diff sometimes list a file that has no changes?

git diff and other git operations is optimized so it does not even look at files whose status (size, modification time etc) on disk and in git's index are different. This makes git diff extremely fast for small changes. If the file has been touched somehow, git diff has to look at the content of and compare it which is a much slower operation even when there is in fact no change. git diff lists the files as a reminder that it is not used optimally. Running git status will not only show status, but will also update the index with status for unchanged files disk making subsequent operations, not only diff, much faster. A typical case that causes many files to be listed by diff is running mass editing commands like perl -pi -e '...'.

为什么 git diff 有时会列出一个没有更改的文件？

git diff 和其他 git 操作经过优化，因此它甚至不会查看磁盘和 git 索引中状态（大小、修改时间等）不同的文件。这使得 git diff 对于小的更改非常快。如果文件以某种方式被触及， git diff 必须查看内容并进行比较，即使实际上没有变化，这也是一个慢得多的操作。git diff 列出文件作为提醒，它没有被最佳使用。运行 git status 不仅会显示状态，还会更新未更改文件磁盘状态的索引，从而进行后续操作，不仅是 diff，而且速度更快。导致许多文件被 diff 列出的典型情况是运行大量编辑命令，如 perl -pi -e '...'。

What does git statusshow for you?

什么是git status显示你？

回答by Nate Cook

After copying my local repository and working copy to another folder (on Windows by the way), I had four files that kept showing up as changed and tried every suggestion listed in the other answers. In the end what fixed it for me was deleting the local branch and downloading it again from the remote. In my case I guess it had something to do with copying a local repository rather than cloning.

将我的本地存储库和工作副本复制到另一个文件夹（顺便说一下在 Windows 上）后，我有四个文件一直显示为已更改，并尝试了其他答案中列出的每个建议。最后为我修复的是删除本地分支并从远程再次下载它。就我而言，我猜这与复制本地存储库而不是克隆有关。