4

我在 Windows 上使用 git (1.8.3)。如果我从 github 克隆一个 repo，然后立即在该 repo 上签出一个不同的现有分支，git 会检测到修改过的文件。通常. 有时它不会。所有修改后的文件的差异都相同（包括行尾）。在我的团队中至少有 4 台不同的 PC 上的 2 个不同的存储库中观察到了这个问题。

它并不总是相同的文件，但它几乎总是代表中的几个文件子集之一。例如，有时在 repo 的根目录中有相同的 5 个文件，有时在一个特定文件夹中相同的 93 个文件，有时在不同文件夹中相同的 16 个文件。

一旦 git 将文件标记为已修改，如果我还原或存储它们，它们会立即再次标记为已修改，这使得无法在分支之间来回切换。

我感觉它与行尾有关，但我已经添加了推荐的 .gitattributes 文件并重新规范了每个分支，但我仍然有这些零星的问题。我想到的另一种可能性是分支之间的合并以某种方式弄乱了我所做的重整化，但我不知道如何测试该理论。

我们都拥有core.autocrlf=true，因为我们都在 Windows 上。这是我们的 .gitattributes

# Auto detect text files and perform LF normalization
* text=auto

# Custom for Visual Studio
*.cs      diff=csharp
*.sln     merge=union
*.csproj  merge=union
*.sqlproj merge=union
*.html    text diff=html
*.css     text
*.js      text
*.ejs     text
*.sql     text

# Standard to msysgit
*.doc     diff=astextplain
*.DOC     diff=astextplain
*.docx    diff=astextplain
*.DOCX    diff=astextplain
*.pdf     diff=astextplain
*.PDF     diff=astextplain
4

2 回答 2

4

有两种情况我见过这种事情发生：

  • 行尾和 Git 尝试跨平台处理的所有疯狂选项。（我自己根本不使用这些功能，我更喜欢存储和处理所有具有一致 LF 行结尾的文件，包括在 Windows 上。）

  • 具有两个或多个文件的存储库，这些文件的名称仅在大小写时不同。例如，readme.txt和ReadMe.txt。Windows 上的 Git 很难处理这些情况，因为只有一个底层文件可以通过两个不同的名称访问。

于 2013-09-04T03:59:30.840 回答
2

从不设置core.autocrlf为true，总是设置为false。

就这么简单：这是一个具有意想不到后果的全球环境。

如果您有特定类型的文档要根据 eol 进行管理，请仅通过.gitattributesfiles和core.eoldirectives进行。

这意味着：首先摆脱自动更改目录（如您的* text=auto），将该修改推送回上游存储库，然后查看问题是否仍然存在。

然后，并且仅在那时，重新引入这些指令，而不是针对每个文件（不是针对' *'），而仅针对您绝对希望 eol 标准化的文件。
并检查是否有效。

于 2013-09-09T06:05:20.617 回答