为什么git认为一个未触及的文件的每一行都发生了变化 [英] Why does git think each line of an untouched file has changed

查看:201
本文介绍了为什么git认为一个未触及的文件的每一行都发生了变化的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我不认为这是行结尾差异问题 - p4merge不认为文件中有任何变化,即使设置为识别行尾和空白区别。



我的问题是,有时会发生以下情况:


  • 起初 git status 显示没有未提交的更改。
  • 然后我签出另一个分支
  • 现在 git status 列表一些文件被更改。
  • git diff 在任何这些已更改的文件上显示文件的每一行被更改。更改后的版本与原始版本相同。



为什么会发生这种情况?为什么git认为这些文件已经改变了,当他们似乎没有做到这一点?为什么只检查出另一个分支会导致这种情况?



我的第一个想法是行结束,但我不知道为什么p4merge不会检测到这些结果。第二个想法是文件模式的变化。我不知道如何确定是否是这种情况。 git config --list 显示core.filemode设置为false。 git config --global --list git config --system --list 不显示任何设置core.filemode(我在这里告诉这个,因为我不知道配置级别如何互相覆盖)。 core.autocrlf设置为true。

多个开发人员都致力于从Windows计算机上提取所有更改的存储库。我猜在某个地方有人设置了一个导致这种情况的位置,但我不知道它是我本地还是其他人,或者它可能是什么设置。



列为已更改的文件似乎不是随机的 - 如果我删除了我的本地存储库,再次从远程克隆它(默认为正在检出的主分支),并再次检出同一分支, git status 每次都列出与更改完全相同的文件。这些文件有时候是最近编辑过的,有时候是多年以来没有被触及的文件。它们不仅是二进制文件(已知 core.autocrlf = true 有时会被破坏),还有文本文件。



执行命令 git rm --cached -r。后跟 git reset --hard gets摆脱这些变化,但它经常发生变得令人烦恼。我也很好奇这是什么原因造成的。



同一个存储库也会导致行结束问题。我认为这是一个单独的问题,所以我最终可能会为此提出另一个问题,但我在此简要提及它以防万一它是相关的。检出另一个分支或从远程存储库中提取更改有时会导致文件显示为已更改,并且这些文件上的 git diff 仅输出警告:LF将被替换由CRLF在[档案]。该文件将在工作目录中具有其原始行结束符。



编辑:存储库的.gitattributes文件仅包含<$
$ b

的输出git config --list * text = auto / code>(省略了诸如颜色,文件路径,编辑器,远程,difftool,用户名和电子邮件等设置的设置):

  core.symlinks = false 
core.autocrlf = true3
pack.packsizelimit = 2g
rebase.autosquash = true
merge.summary = true
core.repositoryformatversion = 0
core.filemode = false
core.bare = false
core.logallrefupdates = true
core.symlinks = false(是的,这里有两次,只是注意到)
core.ignorecase = true
core.hidedotfiles = dotgitOnly


解决

  git diff --word-diff 

-regex =。

这会标记所有更改的字符,甚至是空格。



很可能它会显示行结尾的变化。如果你正在使用Windows并打开 core.autocrlf ,git可能会预期另一种行结束,并显示错误行结束为diff。



通过关闭 core.autocrlf 来告诉git不关心行结束符应该解决您的问题。


I don't think it's a line ending difference issue - p4merge does not think anything has changed in the file, even when set to recognize line ending and white space differences.

My issue is that sometimes the following happens:

  • At first git status shows no uncommitted changes.
  • Then I checkout another branch
  • Now git status lists some files as changed.
  • git diff on any of those "changed files" shows every line of the file as changed. The changed version appears the same as the original version.

Why is this happening? Why does git think the files have changed, when they appear to not have done that? Why does just checking out another branch cause this?

My first thought was line endings, but I don't know why p4merge would not detect those. Second idea was file mode changes. I don't know how to find out if that's the case. git config --list shows core.filemode is set to false. git config --global --list and git config --system --list don't show any setting for core.filemode (I tell this here since I'm not sure how different config levels override each other). core.autocrlf is set to true.

Multiple developers commit to the same repository I'm pulling changes from, all on Windows machines. I'm guessing someone somewhere has some setting in a position that's causing this, but I don't know if it's me locally or someone else, or what setting it could be.

The files listed as changed don't appear to be random - if I delete my local repository, clone it again from the remote (which defaults to master branch being checked out), and checkout that same branch again, git status lists the exact same files as changed, every time. The files are sometimes something recently edited, sometimes files that have not been touched in years. They are also not only binary files (that core.autocrlf=true is known to corrupt at times), but text files as well.

Doing commands git rm --cached -r . followed with git reset --hard gets rid of the changes, but it's occurring so often it's getting bothersome. I'm also curious what could be causing this.

Same repository is also causing line ending problems. I think this is a separate issue, so I'll probably end up making another question for it, but I mention it here briefly in case it's related after all. Checking out another branch or pulling changes from remote repository sometimes causes files appear as changed, and git diff on those files only outputs warning: LF will be replaced by CRLF in [file]. The file will have its original line endings in your working directory.

Edit: The .gitattributes file of the repository has only the line * text=auto and nothing else in it.

Output of git config --list (ommitted settings with things like colors, file paths to editor, remote, difftool, user name and email and such):

core.symlinks=false
core.autocrlf=true3
pack.packsizelimit=2g
rebase.autosquash=true
merge.summary=true
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false (yes this is there twice, just noticed)
core.ignorecase=true
core.hidedotfiles=dotgitOnly

解决方案

To show such "invisible" changes in details use:

git diff --word-diff-regex=.

This will mark all changed characters, even whitespace.

Most probably it will show a change in line endings. If you are working on Windows and turned on core.autocrlf, git might expect the other kind of line ending and show the "wrong" line ending as diff.

Telling git to not care about line endings by turning off core.autocrlf should fix your issue.

这篇关于为什么git认为一个未触及的文件的每一行都发生了变化的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆