如何修复GIT存储库中的CRLF以避免合并冲突 [英] How to repair CRLF in GIT repository to avoid merge conflicts

问题描述

我使用 autocrlf = true 创建了我的回购库，然后进行了一些结账并提交了 autocrlf = false 。然后切换回 autocrlf = true （OS Win）。
一切似乎都没有问题，直到我开始在分支机构之间进行合并。出现许多合并冲突，其中整个文件由于更改而被标记为已更改 eols （我想这些文件已签出并用 autocrlf =假）。

有一些历史记录，这对我来说是值得的，所以我更愿意转换或修改转换后的 eols



这就是我的理解 autocrlf （OS Win）：
$ b $如果 autocrlf = true

  WorkingTree  - >提交 - > GITRepository 
 CRLF CRLF到LF LF 
 LF没有转化。 LF 
 WorkingTree<  - 结帐<  -  GITRepository 
 CRLF LF到CRLF LF 
  



<如果 autocrlf = false

  WorkingTree  - >提交 - > GITRepository 
 CRLF没有转化。 CRLF 
 LF没有转化。 LF 
 WorkingTree<  - 结帐<  -  GITRepository 
 CRLF no conv。 CRLF 
 LF没有转化。 LF 
  

现在我想使用GIT和 autocrlf = false ，所以我决定检查每个分支，用实用程序修复 eols 源文件 EOL转换器并使用CRLF提交。我做到了，但过了一段时间，仍然有一些文件，在将 autocrlf 设置更改为 false （或者这些文件是从较旧的未固定提交中合并的？在转换期间，我使用了掩码* .filetype自动处理所有LF到CRLF，因此对于这种情况我没有其他解释）。
我也尝试过 touch 这些文件，重新提交它们（正如我在这里看到的，在stackoverflow中），但日期更改与GIT AFAIK无关。我还阅读了如何撤销autocrlf 的损坏，但不能

请问我该如何避免这种混乱？

解决方案

对于递归策略，使用git合并选项ignore-space-change或ignore-all-space。该选项至少在1.7.4.1中。

I created my repo with autocrlf=true and then made some checkouts and commits with autocrlf=false. Then switched back to autocrlf=true (OS Win). Everything seemed to be OK, until I started some merges between branches. Many merge conflicts arose, where whole file was marked as changed due to changed eols (I suppose it were those files, which were checked out and commited with autocrlf=false).

There is some history, which is worth for me, so I prefer to make some conversion or fixing commits with converted eols rather to creating new repo and starting new life.

This is how I understand autocrlf (OS Win):

case if autocrlf=true

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

case if autocrlf=false

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

Now I would like to use GIT with autocrlf=false, so I decided to checkout each branch, repair eols of source files with utility EOL converter and commit back with CRLF. I did it, but after time, there are still some files, which probably were not checked out after I changed setting of autocrlf to false (or these files came to merge from older not fixed commits? During conversion I used mask *.filetype to automate processing all LF to CRLF so there's no other explanation for such situation for me). I also tried to touch the files, to re-commit them all (as I saw somewhere here in stackoverflow) but date change is not relevant for GIT AFAIK. I have also read How to undo the damage of autocrlf, but not sure it's my case, and also don't understand the wizard's tricks.

How can I get away from this mess, please?

解决方案

Use the git merge option "ignore-space-change" or "ignore-all-space" for the "recursive" strategy. This option is in 1.7.4.1, at least.

这篇关于如何修复GIT存储库中的CRLF以避免合并冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！