12

我使用创建了我的存储库，autocrlf=true然后使用autocrlf=false. 然后切换回autocrlf=true（OS Win）。一切似乎都很好，直到我开始在分支之间进行一些合并。出现了许多合并冲突，其中整个文件被标记为因更改而更改eols（我想是那些文件，它们被签出并提交autocrlf=false）。

有一些历史，这对我来说是值得的，所以我更喜欢进行一些转换或修复提交，eols而不是创建新的 repo 并开始新的生活。

这就是我的理解autocrlf（OS Win）：

情况如果autocrlf=true

WorkingTree ->  commit  -> GITRepository
CRLF         CRLF to LF      LF
LF           no conv.        LF
WorkingTree <- checkout <- GITRepository
CRLF         LF to CRLF      LF

情况如果autocrlf=false

WorkingTree ->  commit  -> GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF
WorkingTree <- checkout <- GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF

现在我想将 GIT 与. 一起使用autocrlf=false，所以我决定检查每个分支，使用实用程序EOL 转换器eols修复源文件并使用 CRLF 提交。我做到了，但是一段时间后，仍然有一些文件，在我将设置更改为之后可能没有检出（或者这些文件是从较旧的非固定提交合并而来的？在转换过程中，我使用掩码 *.filetype 来自动处理所有 LF 到 CRLF，所以对我来说这种情况没有其他解释）。我还尝试了文件，重新提交所有文件（正如我在stackoverflow中看到的那样），但日期更改与GIT AFAIK无关。我还阅读了如何撤消 autocrlf 的损坏autocrlffalsetouch，但不确定是我的情况，也不懂巫师的把戏。

请问我怎样才能摆脱这种混乱？

4

2 回答 2

1

使用 git 合并选项“ignore-space-change”或“ignore-all-space”作为“递归”策略。这个选项至少在 1.7.4.1 中。

于 2011-09-22T18:38:08.743 回答
-1

简单的回答：除非您正在使用非 Windows 进行 x 平台开发，否则将其设置为 false。您的源代码控制无需为您的文件混蛋。解决任何剩余问题后，您应该飞行。确保与您一起工作的其他人也将其设置为 false。

于 2011-12-29T20:05:41.000 回答