git-merge 是否可以忽略行结束差异？

Question

git merge 是否可以忽略行结束差异？

也许我问错了问题......但是：

我尝试了 uisng config.crlf input 但事情变得有点混乱并且失控，特别是当我事后应用它时 /em>.

一方面，事后应用此配置似乎不会影响在应用此选项之前提交到存储库的文件。 另一件事是，突然间所有提交都会导致许多有关 CRLF 转换为 LF 的恼人警告消息。

老实说，我并不关心使用什么换行符，我个人更喜欢 Unix 风格 \n，但无论如何。 我所关心的只是让 git merge 变得更聪明并忽略行结尾的差异。

有时我有两个相同的文件，但 git 会将它们标记为冲突（冲突是整个文件），只是因为它们使用不同的行结束字符。

更新：

我发现 git diff 接受 --ignore-space-at-eol 选项，是否可以让 git merge也使用这个选项吗？

Answer 1

阅读https://stackoverflow.com/a/12194759/1441706和https://stackoverflow.com/a/14195253/1441706

对我来说，这个命令完美地完成了任务：

git merge master -s recursive -X renormalize

Answer 2

不过我建议使用 sed 等工具来实现正确的行结尾，然后比较文件。 我花了几个小时来比较具有不同行结尾的项目。

最好的方法是：

1. 仅将项目文件（省略 .git 目录）复制到另一个目录，在其中创建存储库，然后添加文件并提交它们（应该位于新存储库的 master 分支上）。
2. 将文件从第二个项目复制到同一文件夹，但另一个分支例如 dev (git checkout -b dev)，在此分支上提交文件并运行（如果第一个项目位于掌握）：
   git diff master..dev --names-only
   仅查看已更改文件的名称

Answer 3

2013 年更新：

较新的 git 版本授权使用策略递归和策略选项（-X）进行合并：

• 来自“Git 合并并修复具有两个分支的混合空间和选项卡"：

  git merge -s recursive -Xignore-space-at-eol 
    

但使用“-Xignore-space-change”也是一种可能性

• Fab-V 提到下面 :

  git merge master -s recursive -X renormalize 
    

---

jakub.g 还有评论，策略也适用于挑选：

git cherry-pick abcd123456 --strategy=recursive --strategy-option=renormalize 

这比ignore-all-space效果要好得多。

---

在 Git 2.29（2020 年第 4 季度）之前，内部使用合并递归机制的所有“合并”操作都应遵循 merge.renormalize 配置，但其中许多操作并没有这样做。

请参阅 提交 00906d6、提交 8d55225, 提交 6f6e7cf，提交 fe48efb（2020 年 8 月 3 日），作者：伊利亚·纽伦 (newren)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 4339259，2020 年 8 月 10 日）}

合并：使merge.renormalize 适用于合并机制的所有用途

^{签字人：伊利亚·纽伦}

“merge”命令并不是唯一进行合并的命令； 其他命令如 checkout -m 或 rebase 也可以。

不幸的是，检查“merge.renormalize”配置设置的代码的唯一区域位于builtin/merge.c，这意味着它只能影响由“merge”执行的合并命令。

将此配置设置的处理移至 merge_recursive_config()，以便其他命令也可以从中受益。

---

原始答案（2009年5月）

忽略 eol 样式的补丁已在 2007 年 6 月，但它只涉及 git diff --ignore-space-at-eol，而不是 git merge。

当时有人问这样的问题：

--ignore-space-at-eol 应该是 git-merge 的一个选项吗？
合并是此功能最重要的地方。
自动解析合并与这些有效选项的语义是什么——它们是否仅用于重命名检测，或者我们是否仅使用空格更改来标记冲突？ 如果不这样做，我们会自动接受哪个版本？

Julio C Hamano 并不是很热情：

这当然很诱人，但我怀疑应该留到以后的回合。
我怀疑它会引入两种不同类型差异的概念，一种是机械处理的（即与“git-merge-recursive”合并使用，并应用
“git-am”），另一个由人类检查以理解。
对于后一种情况，整理输入通常可能很有用，即使比较整理的输入文件的输出可能不容易用于机械应用程序。

当谈到git merge时，一般的想法是依赖第三方合并工具。

例如，我设置了DiffMerge 成为 Git 合并工具，设置一个规则集，允许合并工具忽略某些类型文件的 eol 。

---

在 Windows 上使用 MSysGit1.6.3 进行设置，对于 DOS 或 Git bash 会话，使用 DiffMerge 或 KDiff3：

• 在 PATH 中设置一个目录（此处：c:\HOMEWARE\cmd）。
• 在该目录中添加脚本 merge.sh （您最喜欢的合并工具的包装器）

merge.sh：

#!/bin/sh

# Passing the following parameters to mergetool:
#  local base remote merge_result

alocal=$1
base=$2
remote=$3
result=$4

if [ -f $base ]
then
    #"C:/Program Files/SourceGear/DiffMerge/DiffMerge.exe" "$alocal" "$base" "$remote" -m --result="$result" --title1="Mine" --title2="Merging to: $result" --title3="Theirs"

    # for merge respecting eol, KDiff3 is better than DiffMerge (which will always convert LF into CRLF)
    # KDiff3 will display eol choices (if Windows: CRLF, if Unix LF)
    "C:/Program Files/KDiff3/kdiff3.exe" -m "$base" "$alocal" "$remote" -o "$result"
else
    #there is not always a common ancestor: DiffMerge needing 3 files, BASE will be the result
    #"C:/Program Files/SourceGear/DiffMerge/DiffMerge.exe" "$alocal" "$result" "$remote" -m --result="$result" --title1="Mine" --title2="Merging to: $result" --title3="Theirs"
    
    # KDiff3 however does know how to merge based on 2 files (not just 3)
    "C:/Program Files/KDiff3/kdiff3.exe" -m "$base" "$remote" -o "$result"
fi

• 为 Git 声明您的合并包装器

Git 配置命令：

git config --global merge.tool diffmerge
git config --global mergetool.diffmerge.cmd "merge.sh \"$PWD/$LOCAL\" \"$PWD/$BASE\" \"$PWD/$REMOTE\" \"$PWD/$MERGED\"
git config --global mergetool.diffmerge.trustExitCode false
git config --global mergetool.diffmerge.keepBackup false

• autoCRLF 是否为 false

检查系统级别的

git config ---system core.autoCRLF=false

• git config： 测试一下，当两个行是相同的（但它们的 eol 字符），DiffMerge 或 KDiff3 在合并期间都会忽略这些行。

DOS 脚本（注意：dos2unix 命令来自此处，用于模拟 Unix eol 风格。该命令已复制到本答案开头提到的目录中。）：

C:\HOMEWARE\git\test>mkdir test_merge
C:\HOMEWARE\git\test>cd test_merge
C:\HOMEWARE\git\test\test_merge>git init
C:\HOMEWARE\git\test\test_merge>echo a1 > a.txt & echo a2 >> a.txt
C:\HOMEWARE\git\test\test_merge>git add a.txt
C:\HOMEWARE\git\test\test_merge>git commit -m "a.txt, windows eol style"
C:\HOMEWARE\git\test\test_merge>git checkout -b windows
Switched to a new branch 'windows'
C:\HOMEWARE\git\test\test_merge>echo a3 >> a.txt & echo a4 >> a.txt
C:\HOMEWARE\git\test\test_merge>git add a.txt
C:\HOMEWARE\git\test\test_merge>git commit -m "add two lines, windows eol style"
C:\HOMEWARE\git\test\test_merge>git checkout master
C:\HOMEWARE\git\test\test_merge>git checkout -b unix
Switched to a new branch 'unix'
C:\HOMEWARE\git\test\test_merge>echo au3 >> a.txt & echo au4 >> a.txt && echo au5 >> a.txt
C:\HOMEWARE\git\test\test_merge>dos2unix a.txt
Dos2Unix: Processing file a.txt ...
C:\HOMEWARE\git\test\test_merge>git add a.txt
C:\HOMEWARE\git\test\test_merge>git commit -m "add 3 lines, all file unix eol style"
[unix c433a63] add 3 lines, all file unix eol style

C:\HOMEWARE\git\test\test_merge>git merge windows
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.

C:\HOMEWARE\git\test\test_merge>git ls-files -u
100644 39b4c894078a02afb9b1dfeda6f1127c138e38df 1       a.txt
100644 28b3d018872c08b0696764118b76dd3d0b448fca 2       a.txt
100644 3994da66530b4df80189bb198dcfac9b8f2a7b33 3       a.txt

C:\HOMEWARE\git\test\test_merge>git mergetool
Merging the files: a.txt

Normal merge conflict for 'a.txt':
  {local}: modified
  {remote}: modified
Hit return to start merge resolution tool (diffmerge):

此时（点击“return”）。 ")，DiffMerge 或 KDiff3 将打开，您将亲眼看到哪些行被实际合并，哪些行被忽略。

警告：使用 DiffMerge 时结果文件将始终处于 Windows eol 模式 (CRLF)...
KDiff3 提供以一种或另一种方式保存。

Answer 4

我一直在寻找相同的答案，我发现这个

合并具有不同签入/签出属性的分支

如果您向文件添加了导致规范的属性
要更改该文件的存储库格式，例如添加
清洁/涂抹过滤器或文本/eol/ident 属性，合并任何内容
属性不存在的地方通常会导致合并
冲突。

为了防止这些不必要的合并冲突，可以告诉 git 运行
虚拟签出和签入文件的所有三个阶段
通过设置 merge.renormalize 解决三向合并
配置变量。 这可以防止因签入而导致的更改
转换时避免转换文件时导致虚假合并冲突
与未转换的文件合并。

只要“smudge→clean”会产生与“clean”相同的输出
即使对于已经被弄脏的文件，此策略也将
自动解决所有与过滤器相关的冲突。 过滤器可以做到
不以这种方式行事可能会导致额外的合并冲突，必须
手动解决。

因此，在任何存储库中运行此命令都可以解决问题：

git config merge.renormalize true

Answer 5

正如这个答案： https://stackoverflow.com/a/5262473/943928

你可以尝试： git合并-s递归-Xignore-space-at-eol

Answer 6

我所做的是将所有内容保留为默认值（即 autocrlf=true），触摸所有文件（find . -exec touch {} \;），让 git 将它们视为“已修改”并将它们提交回来，然后完成。 否则，你要么总是被烦人的消息或令人惊讶的差异所困扰，要么不得不关闭 git 的所有空白功能。

你会失去责备信息，但最好是早点做而不是晚点:)

Answer 7

“git merge -Xrenormalize”就像一个魅力。

Answer 8

现在在我看来，最好的方法是在合并两个分支（和提交）之前规范化它们的行结尾。

我用谷歌搜索“将 crlf 转换为 lf”，发现这是第一个结果：
http://stahlforce.com/dev/index.php?tool=remcrlf

我下载并使用了它，看起来是一个不错的工具。

>sfk remcr . .py

请务必指定目录和文件类型（例如 .py），否则它可能会尝试弄乱 .git 目录的内容！

Answer 9

AFAICT，（我还没有尝试过）您可以使用 git diff 来比较要合并到共同祖先的分支，然后使用 git apply 应用结果。 这两个命令都有 --ignore-whitespace 选项来忽略行尾和空格错误。

不幸的是，如果补丁没有完全应用，整个操作就会中止。 您无法修复合并冲突。 有一个 --reject 选项可以在 .rej 文件中保留不可修补的块，这会有所帮助，但与在一个文件中显示合并冲突不同。

Answer 10

阅读解决合并冲突：强制覆盖所有文件后，

我终于解决了这个问题的版本。 我试图从上游存储库中提取更新，但我当前的存储库存在 CRLF 相关问题，因此无法合并。 应该指出的是，我没有需要担心的局部变化。 以下步骤解决了我的问题：

按照 github 关于同步分叉的说明 (https:// help.github.com/articles/syncing-a-fork/):

1. git fetchupstream

2. git重置--hard上游/master
   我对 git 的有限理解告诉我，这正在做我想做的事——重新调整我的分支（没有实际未提交的更改）以获得对上游源代码所做的所有更改。 根据源页面，通常不需要此步骤，但 CRLF 问题使其成为必需。

3. git 合并上游/master

4. git Push