让Git在其“<<<<<<<<<< HEAD"合并行 [英] Make Git use CRLF on its "<<<<<<< HEAD" merge lines

问题描述

$ b

如果在不可见的文本编辑器中解决冲突EOL字符，如果你通过选择删除，很容易意外地结束这些LF合并：

离开你：

< img src =https://i.stack.imgur.com/wEnpm.pngalt =LFs潜入文件！>

现在两个LF有潜入其他CRLF文件！

很明显，另一种方法是在解决合并时更加小心线结束，但我想我会问，如果有一种告诉Git在它生成的行中使用CRLF的方法。

解决方案

有可能要求Git使用CRLF，而不是仅在LF放入文件时使用CRLF。 >它...实际上是可能的，从 git 2.7.2+（February 2016）。

您无需执行任何操作。

请参阅 commit 15980de ，提交86efa21 （2016年1月27日）作者： Johannes Schindelin（ dscho ）。

^{（由 Junio合并C Hamano - gitster - 在 commit ab2c107 ，2016年2月17日）}

合并-file ：让冲突标记匹配上下文的行尾样式

合并具有CR / LF行结尾的文件时，冲突标记应该与
相匹配，以免输出文件中出现混合行尾。

这在Windows中尤其引人关注，编辑们真的被混合线结尾困惑了。

Beat Bolli的这个补丁的原始版本尊重 core.eol 和
a此开发人员的后续改进也受到尊重 gitattributes 。

此方法是-optimal，尽管： git merge-file 被发明为GNU合并的
替代品，因此在运行
之外没有任何问题任何存储库！

原始方法的另一个问题被指出ou t by Junio
Hamano：传统版本库可能使用
CR / LF行结尾（ core.eol ）和 gitattributes 会给我们带来
的错误印象）。因此，更优越的方法是
简单地匹配上下文的行结尾（如果有的话）。

我们实际上不必完全看看整个上下文：

• 如果这些文件全是纯文本文件，或者全部是有CR / LF行结束符，仅查看一个单行行就足以匹配该样式。


• 如果行结尾仍然是混合的，那么仍然可以模仿一行代码：我们只会添加到一堆混合行结尾，
  ，我们无能为力。

所以我们做的是：我们看前面的行冲突将
下降回到最后一行的情况之前的行，并且没有
行结尾，回到第一行，首先在第一个
后期图像中，然后是第二个后期图像，最后是前期图像。

如果我们发现一致的CR / LF（或未定）线条样式，我们匹配
，否则我们使用仅限LF的冲突标记行结束。

请注意，虽然确实至少有两行我们可以看
（否则没有冲突），对于 endings 行也是如此：
：这三个文件可能都包含一个
单行，而没有任何行结尾，每个。在这种情况下，我们使用LF-only回到
。

Is it possible to ask Git to use CRLF instead of just LF at the end of the lines it puts into a file when it needs merging?

If resolving conflicts in a text editor without visible EOL characters, it is easy to accidentally end up with these LFs getting merged if you delete by selection:

Leaving you with:

And now two LFs have sneaked their way into your otherwise CRLF file!

Obviously one alternative is to just take more care over line endings when resolving merges, but I thought I would ask in case there were a way to tell Git to use CRLF for the lines it generates here.

解决方案

Is it possible to ask Git to use CRLF instead of just LF at the end of the lines it puts into a file when it needs merging?

It... actually is possible, from git 2.7.2+ (February 2016).
And you don't have to do anything.

See commit 15980de, commit 86efa21 (27 Jan 2016) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit ab2c107, 17 Feb 2016)}

merge-file: let conflict markers match end-of-line style of the context

When merging files with CR/LF line endings, the conflict markers should match those, lest the output file has mixed line endings.

This is particularly of interest on Windows, where some editors get really confused by mixed line endings.

The original version of this patch by Beat Bolli respected core.eol, and a subsequent improvement by this developer also respected gitattributes.
This approach was sub-optimal, though: git merge-file was invented as a drop-in replacement for GNU merge and as such has no problem operating outside of any repository at all!

Another problem with the original approach was pointed out by Junio Hamano: legacy repositories might have their text files committed using CR/LF line endings (and core.eol and the gitattributes would give us a false impression there). Therefore, the much superior approach is to simply match the context's line endings, if any.

We actually do not have to look at the entire context at all:

• if the files are all LF-only, or if they all have CR/LF line endings, it is sufficient to look at just a single line to match that style.
• And if the line endings are mixed anyway, it is still okay to imitate just a single line's eol: we will just add to the pile of mixed line endings, and there is nothing we can do about that.

So what we do is: we look at the line preceding the conflict, falling back to the line preceding that in case it was the last line and had no line ending, falling back to the first line, first in the first post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match that, otherwise we use LF-only line endings for the conflict markers.

Note that while it is true that there have to be at least two lines we can look at (otherwise there would be no conflict), the same is not true for line endings: the three files in question could all consist of a single line without any line ending, each. In this case we fall back to using LF-only.

这篇关于让Git在其“&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD&QUOT;合并行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！