简体繁体 English

来自申请和藏匿的冲突

[英]Conflicts from apply and stash

原文 2017-11-06 21:32:34 8 1 git

While reading some tutorials/stackoveflow content, I read that conflicts can also occur with stash and apply. 在阅读一些教程/ stackoveflow内容时，我读到了存储和应用也会发生冲突。

For example: (From git-scm/git-apply---3way 例如:(来自git-scm / git-apply --- 3way

-3 -3

--3way --3way

When the patch does not apply cleanly , fall back on 3-way merge if the patch records the identity of blobs it is supposed to apply to, and we have those blobs available locally, possibly leaving the conflict markers in the files in the working tree for the user to resolve. 当补丁不能干净地应用时 ，如果补丁记录了它应该应用的blob的身份，则回退到三向合并，并且我们在本地可以使用这些blob，可能会将冲突标记留在工作树中的文件中供用户解决。 This option implies the --index option, and is incompatible with the --reject and the --cached options. 此选项隐含--index选项，与--reject和--cached选项不兼容。

Is When the patch does not apply cleanly equal to getting conflicts? When the patch does not apply cleanly于发生冲突吗？

How can we get conflicts not from merging operations? 我们如何才能解决冲突而不是合并运营？ Are those conflicts any different then merge conflicts? 这些冲突与合并冲突有什么不同？ I would love to see some graph examples. 我很想看到一些图表示例。

1 个解决方案

Is When the patch does not apply cleanly equal to getting conflicts? When the patch does not apply cleanly于发生冲突吗？

No: it is not applied "cleanly" when it cannot find the "context" of a hunk (set of lines on a patch) in the target file (the one where you apply the patch). 否：当它找不到目标文件（应用补丁的那个）中的大块（补丁上的一组行）的“上下文”时，它不会“干净地”应用。
A patch is using " context diffs " and " unified diffs " (also known as "unidiffs"), which surround each change with context lines (lines that are supposed to be before and after the modification to apply), as well as range (line number where the modification occurs). 补丁正在使用“ 上下文差异 ”和“ 统一差异 ”（也称为“unidiffs”），它们围绕每个变化包含上下文行（应该在修改之前和之后应用的行），以及范围（发生修改的行号）。 A patch can then use this "context" to locate the region to be patched even if it has been displaced by changes earlier in the file, using the line numbers in the diffs as a starting point. 然后，补丁可以使用此“上下文”来定位要修补的区域，即使它已经被文件中较早的更改所替换，也可以使用差异中的行号作为起点。

But if the modifications of the target do interfere with the patch (meaning: if the context is no longer there in the target file, because of modified or deleted lines), then it (the patch) does not apply cleanly. 但是如果目标的修改确实干扰了补丁（意思是：如果目标文件中的上下文不再存在，因为修改或删除了行），那么它（补丁）不能干净地应用。

How can we get conflicts not from merging operations? 我们如何才能解决冲突而不是合并运营？

You only get merge conflict when switching to a 3-way merge . 切换到3向合并时，只会出现合并冲突。
In that case, you have a common ancestor which gives you the ability to know whether or not a chunk is a change from the origin and whether or not changes conflict. 在这种情况下，您有一个共同的祖先，它使您能够知道块是否是来自原点的更改以及更改是否发生冲突。
See more on the three-way merge in " Guiffy SureMerge - A Trustworthy 3-Way Merge ". 在“ Guiffy SureMerge - 值得信赖的3-Way Merge ”中查看有关三向合并的更多信息。