问题描述
当某个提交（递归合并）有两个父提交时，如第二个父节点是我们合并到的分支上的提交，这意味着包含所有该合并提交引入的更改。这对于递归合并是可以的。但如果它是 octopuss合并就像我们如何确定哪个提交引入了哪些更改？提前致谢 - 增加了一些关于基于差异的方法的说明
$ b
说第二个父代是正常合并中所有更改的来源有些误导。可能会有手动冲突解决方案，或者有人可能只是合并 - no-commit 选项，并在合并期间引入其他更改。它更适用于考虑合并方式与其父母的不同之处，而不是考虑哪个父母介绍每个变更。
然而，它可以是有用来根据这种变化从何而来进行思考。取决于你可以从以下其中一个开始的信息：
1） git blame 告诉你每行代码的来源提交。任何源自 HEAD ^ .. branchN 的提交都必须在 branchN 上指示更改。但是由于您提供的信息是每行代码的提交ID，因此需要进行相当多的后处理才能将更改归零。
2）你可以为每个分支做一个差异。原本我在想
git diff HEAD ^ HEAD ^ 2
等等（用每个合并分支的引用替换 HEAD ^ 2 ）。这是可以的，除非主分支在其他分支发散后发生了很大的变化（在这种情况下，这些变化的倒数会出现在每一个差异中）。
要求的是每个分支尖端与分支开始发散的点之间的差异;所以如果你可以找到共同的祖先，也许只是使用它：
git diff A HEAD ^ 2
（其中 A 是可从 HEAD ^ 和 HEAD ^ 2 ）。虽然这是一种直接表达（对于一次分支）的确切含义，但它确实需要在每种情况下追踪共同的祖先。 （可能有一个很好的快捷方式，我没有想到;如果发生在我身上，我会回来一个更新。）
如果分支拓扑是太乱了，这可能还是有点不清楚。例如，如果 branch3 实际上是从 branch2 分支的，那么您必须决定是否意味着diff branch3 与 HEAD 或 branch2 共同的祖先以前的方法意味着一些改变将被归于 branch2 和 branch3 ）。
使用单个命令生成所有差异会很好，表面上这就是 -m 选项到 log 或 show 会做;但是这会将我们带回到我的答案的开始，因为您正在获取与每个分支合并的差异（而不是每个分支引入的更改），并且必须在心理上否定每个更改。 （也就是说，您必须查找diff 不包含更改的一个分支，以知道该更改的来源）。
When a certain commit (recursive merge) has 2 parent commits, as mentioned in here the second parent is the commit on the branch that we merged in, which means containing all the changes introduced by that merge commit. This is ok for recursive merge. But if it a octopuss merge like this how do we identify which commit introduce which changes?. Thanks in advance
UPDATE - Added some clarification about diff-based approach
It's somewhat misleading to say that the second parent is the source of all changes in a normal merge. There may be manual conflict resolution, or someone may just merge with the --no-commit option and introduce additional changes during the merge itself. It's more generally applicable to think in terms of how the merge differs from each of its parents, than to think of which parent introduced each change.
Still, it can be useful to think in terms of "where did this change come from". Depending on what information you're really after you could start with one of these:
1) git blame will tell you the commit from which each line of code originates. Anything that originates from a commit in HEAD^..branchN must indicate a change on branchN. But since the info you're given is a commit ID for each and every line of code, considerable post-processing would be needed to zero in on changes.
2) You could do a diff for each branch. Originally I was thinking
git diff HEAD^ HEAD^2
and so on (replacing HEAD^2 with a reference to each merged branch). This is ok, except if the main branch has changed much since the other branches diverged (in which case the inverse of those changes would appear in every diff).
What you really are asking for is the diff between each branch tip and the point where that branch started to diverge; so if you can locate the "common ancestor", maybe just use that:
git diff A HEAD^2
(where A is the latest commit reachable from both HEAD^ and HEAD^2). While this is a straight-forward way to express (for one branch at a time) exactly what you mean, it does require tracking down the common ancestor in each case. (There may be a good shortcut I'm not thinking of; I'll come back with an update if it occurs to me.)
And if the branch topology is too messy, this may still be somewhat unclear. For example, if branch3 was actually branched from branch2, then you'd have to decide whether you mean to diff branch3 against the common ancestor with HEAD or with branch2 (the former approach meaning some changes would be ascribed to both branch2 and branch3).
It would be nice to use a single command to generate all the diffs, and on the surface this is what the -m option to log or show would do; but this takes us back to the start of my answer, as you're getting the difference of the merge with each branch (not the changes introduced by each branch) and have to mentally negate each change. (i.e. you would have to look for the one branch whose diff doesn't include a change to know where that change came from).
这篇关于如何确定哪个提交引入了octopuss合并中的哪些更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！