Git显示相同的文件已更改 [英] Git showing identical files as changed

问题描述

当我似乎无法找出更改时，Git向我显示了整个文件已更改.这是cygwin git，但它也发生在msysgit

中

  $ git --versiongit版本2.1.1$ diff<(git show HEAD:File.cs)<(cat File.cs)//没有差异$ diff<(git show HEAD:File.cs | xxd)<(xxd File.cs)//没有差异$ git diff//显示整个文件已更改$ git hash-object<(git show HEAD:File.cs)7b3762473342a5b040835bfef9f6b45c109ba48b$ git hash-object<(cat File.cs)7b3762473342a5b040835bfef9f6b45c109ba48b$ git hash-object File.cs7b3762473342a5b040835bfef9f6b45c109ba48b 

我有

  $ git config --get core.fileMode错误的 

和

  $ git config --get core.autocrlf真的 

我真的不知道发生了什么，所有事情都希望它们相同，但是git想创建一个提交，说所有内容都被删除并重新创建.有谁了解git plumbing更好的建议吗?我能想到的就是git show正在删除/规范化奇数行结尾.

更新:

我很确定它的发生，因为开发过程就是这样.从git签出，将rsync同步到开发机，进行开发，然后rsync返回.我相信rsync会使行尾有些混乱.奇怪的是gits没有报告行结尾，并且似乎对到底发生了什么感到非常困惑.即使差异化文件的二进制表示形式似乎相同.

更新2:

这真是太烦人了，我觉得我偶然发现了git中的错误.

例如

  $ git gc$ git checkout-.$ git clean -fd$ git状态>显示了一堆修改过的文件 

我很确定无论运行在哪里，都不会显示任何更改，但是我得到了20种奇怪的东西的列表:(

解决方案

这可能由 .gitattributes 文件引起，该文件向git指示应进行EOL规范化，但存储库中包含未规范化的行结局.

简单的解决方法是从 .gitattributes 中删除相关行.这可能是

  * text = auto 

或

  *.cs文本 

如何发生这种情况的快速示例如下:

  $ echo"Hello World">example.txt$ unix2dos example.txt#确保它使用CRLF$ git添加example.txt$ git commit -m提交1"$#指示git所有.txt文件都应该规范化$ echo'* .txt文本'>>.gitattributes$ git add .gitattributes$ git commit -m提交2" 

现在存储库处于一种奇怪的状态，因为 .gitattributes 声称应在将文件添加到索引之前对其进行规范化，但是当前提交的版本未进行规范化.

但是，此时， git status 并没有注意到这一点，因为自从文件本身添加到索引以来，文件本身的大小或mtime都没有改变，因此该索引被认为是最新的:

  $ git状态在分支机构主管无需提交，工作目录干净 

但是任何使索引无效的东西都会导致git认为该文件是脏的:

  $ touch example.txt在分支机构主管未暂存的更改未提交:修改:example.txt没有添加任何更改来提交(使用"git add"和/或"git commit -a") 

然后 git reset --hard 或任何其他尝试将文件重置为应该处于的状态的操作都不会解决此问题.这是因为没有办法像在存储库中那样将文件的当前状态添加到索引的当前状态，因为已经指示git对该文件进行规范化，并且规范化永远无法生成对象，因为当前已提交该对象./p>

这就是为什么 GITATTRIBUTES(1)手册页建议在引入行尾归一化时显式使整个索引无效的原因，例如:

  $ echo"* text = auto">> .gitattributes$ rm .git/index#删除索引以强制Git$ git reset#重新扫描工作目录$ git status#显示将被规范化的文件$ git add -u$ git add .gitattributes$ git commit -m引入行尾规范化" 

阅读 gitattributes 手册页中的行尾转换"部分，以了解更多细节.

您可能不希望仅从 .gitattributes 中删除该行，而是要保留行结束规范化规则并立即对其进行规范化.这基本上只是意味着提交20多个不会消失的更改，但是您可以按照上述有关引入行结束规范化的说明(减去编辑 .gitattributes )然后有条不紊地进行操作，从而系统地进行更改.有信心不会再发生这种情况，因为所有文件现在都以规范化的结尾提交，并且将来添加的任何文件也将被规范化.主要是个人喜好.

Git is showing me an entire file is changed, when I can't seem to figure out the changes. This is cygwin git, but it also happens in msysgit

$ git --version
git version 2.1.1

$ diff <(git show HEAD:File.cs) <(cat File.cs)
// Shows no differences

$ diff <(git show HEAD:File.cs | xxd) <(xxd File.cs)
// Shows no differences

$ git diff
// shows the entire file has changed

$ git hash-object <(git show HEAD:File.cs)
7b3762473342a5b040835bfef9f6b45c109ba48b

$ git hash-object <(cat File.cs)
7b3762473342a5b040835bfef9f6b45c109ba48b

$ git hash-object File.cs
7b3762473342a5b040835bfef9f6b45c109ba48b

I have

$ git config --get core.fileMode
false

and

$ git config --get core.autocrlf
true

I truly have no idea what's going on, everything wants them to be the same, yet git wants to create a commit saying the entire contents was deleted and recreated. Does anyone who knows git plumbing better have a suggestion?. All I can think of is git show is removing/normalizing odd line endings.

UPDATE:

I'm pretty sure its happening because development process is like this. Checkout from git, rsync to dev machine, develop, rsync back. I believe rsync is messing with the line endings some. It's just weird that gits not reporting about the line endings, and it seems to get really confused about what the hell is happening. Even though diffing the binary representation of the files seem to be identical.

UPDATE 2:

So this is super annoying, and I feel like I have stumbled upon a bug in git.

For instance

$ git gc
$ git checkout -- .
$ git clean -fd
$ git status

> shows a heap of modified files

I'm pretty sure that should show no changes, no matter where its run, but I get a list of 20 odd things :(

解决方案

This can be caused by a .gitattributes file indicating to git that it should do EOL normalization but the repository containing non-normalized line endings.

The simple fix is to remove the relevant line from .gitattributes. This could be

* text=auto

or

*.cs text

A quick example of how this could happen goes like this:

$ echo "Hello World" > example.txt
$ unix2dos example.txt #Make sure it uses CRLF
$ git add example.txt
$ git commit -m "commit 1"
$ #Instruct git that all .txt files should be normalized
$ echo '*.txt text' >> .gitattributes 
$ git add .gitattributes
$ git commit -m "commit 2"

Now the repository is in a strange state, because .gitattributes claims the file should be normalized before adding it to the index, but the current committed version is not normalized.

However, at this point, git status doesn't notice that, because the file itself has not changed in size or mtime since it was added to the index, so the index is considered to be up to date:

$ git status
On branch master
nothing to commit, working directory clean

But anything which invalidates the index will cause git to consider the file to be dirty:

$ touch example.txt
On branch master
Changes not staged for commit:

        modified:   example.txt

no changes added to commit (use "git add" and/or "git commit -a")

And git reset --hard or any other action to try to reset the file to the state it's supposed to be in will not fix this. This is because there is no way to add the file to the index in it's current state as it is in the repository, because git has been instructed to normalize that file, and that normalization cannot ever produce the object as it currently is committed.

This is why the GITATTRIBUTES(1) man page recommends to explicitly invalidate the entire index when introducing line-ending normalization like so:

$ echo "* text=auto" >>.gitattributes
$ rm .git/index     # Remove the index to force Git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

Read the section on "End-of-line conversion" in the gitattributes man page for more details.

Instead of going with the quick fix of just removing that line from .gitattributes, you may want to instead keep the line ending normalization rules and go ahead and normalize them now. That basically just means committing the 20+ changes that won't go away, but you can do so methodically by following the above instructions about introducing line ending normalization (minus editing the .gitattributes), and then feeling confident that it won't happen again, because all the files are now committed with normalized endings, and any future files you add will also be normalized. It's personal preference, mostly.

这篇关于Git显示相同的文件已更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！