有人可以向我解释git diff在这里看到的有什么不同吗？ [英] Can someone explain to me what difference git diff is seeing here?

问题描述

我通过msysgit在Windows 7上使用git。最近一直引起我很多悲痛的一个问题是，只要我切换到某些分支，git就认为有些文件已被更改，然后我无法做出任何事情来阻止它们认为这些文件已经改变。

在我的情况下重现的步骤（这可能与每个人都不相关）如下：

1. 签出master分支。


2. 签出pristine-3.7分支。


3. 签出pristine-3.8分支。 b $ b
4. 签出pristine-3.9分支。

此时，git开始假定文件已更改。 / p>

例如，以下是一个git diff输出的截图。 $ b

以下是在Hex模式下使用Beyond Compare的同一文件的差异输出。

最后，git状态输出！

发生什么事？

更新问题：

可能的解决方案是在本地提交更改，然后删除提交，而不将提交中的更改重新放回工作状态。如何做到这一点？

解决方案

我经常遇到这个问题 - 唯一可行的是：

  git rm --cached -r。 > / dev / null＃如果输出很大，重定向
 git reset --hard 
  

，但要确保没有要更改的内容

请参阅 git line endings - 不能存储，重置，现在不能存储rebase over spurious line endings commit

有人必须制作一个示例回购，展示此行为并将其发布到git跟踪器 - 这是一个错误（在感觉 git reset --hard 和co应该立即工作）编辑：确保你已经阅读过< a href =http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ =nofollow noreferrer>需要阅读并设置 .gitattributes 文件

I am using git on Windows 7 via msysgit. An issue that has been causing me a lot of grief lately is that as soon as I switch to certain branches, git thinks that some files have been changed and then I can do nothing to make it stop thinking those files have changed.

The steps to reproduce in my case (which might not be relevant to everybody) are as follows:

1. Checkout the master branch.
2. Checkout the pristine-3.7 branch.
3. Checkout the pristine-3.8 branch.
4. Checkout the pristine-3.9 branch.

At this point, git starts to assume that files have changed.

For example, here's a screenshot of a git diff output.

Here's the diff output for the same file using Beyond Compare in Hex mode.

And finally, the git status output!

What's going on?

Update to the question:

A possible solution is to commit the changes locally and then to delete that commit without putting the changes in the commit back into the working state. How is that done?

解决方案

I have this problem constantly - the only thing that works is:

git rm --cached -r . > /dev/null # redirect if output is huge
git reset --hard

but make sure you have no changes you want to keep

See git line endings - can't stash, reset and now can't rebase over spurious line endings commit

Someone must make a example repo that exhibits this behavior and post it to the git tracker - this is a bug (in the sense that git reset --hard and co should work immediately)

EDIT: make sure you have read the required reading and set up a .gitattributes file

这篇关于有人可以向我解释git diff在这里看到的有什么不同吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！