Running git deps on FOO^! is effectively answering the question "which commits would I need in order to be able to cleanly cherry-pick commit FOO?" Drilling down further, that could be rephrased more precisely as "which commits would I need in my current branch in order to be able to cleanly apply the diff which commit FOO applies to its parent?"
However, in the case where FOO is a merge commit with multiple parents, typically the first parent P1 is the parent which is contained by the merge's target branch B1. That means that the merge commit FOO has the effect of applying the diff between P1's tree and the FOO's tree to P1. This could be expressed as:
tree(P1) + diff(tree(P1), tree(FOO)) == tree(FOO)
Therefore the question git-deps needs to answer when operating on a commit with multiple parents is "which commits would I need in my current branch in order to be able to cleanly apply diff(tree(P1), tree(FOO)) to it?"
However, the current algorithm runs the blame analysis not only on diff(tree(P1), tree(FOO)), but on diff(tree(Px), tree(FOO)) for every parent. This is problematic, because for instance if the target branch contains commits which are not on P2's branch, then
diff(tree(P2), tree(FOO))
will regress any changes provided by those commits. This will introduce extra dependencies which incorrectly answer the above question we are trying to answer.
Therefore change the algorithm to only diff against the first parent.
This is very similar in nature to the -m option of git cherry-pick:
aspiers
commented
5 years ago
Running
git depsonFOO^!is effectively answering the question "which commits would I need in order to be able to cleanly cherry-pick commitFOO?" Drilling down further, that could be rephrased more precisely as "which commits would I need in my current branch in order to be able to cleanly apply the diff which commitFOOapplies to its parent?"However, in the case where
FOOis a merge commit with multiple parents, typically the first parentP1is the parent which is contained by the merge's target branchB1. That means that the merge commitFOOhas the effect of applying the diff betweenP1's tree and theFOO'stree toP1. This could be expressed as:Therefore the question git-deps needs to answer when operating on a commit with multiple parents is "which commits would I need in my current branch in order to be able to cleanly apply
diff(tree(P1), tree(FOO))to it?"However, the current algorithm runs the blame analysis not only on
diff(tree(P1), tree(FOO)), but ondiff(tree(Px), tree(FOO))for every parent. This is problematic, because for instance if the target branch contains commits which are not on P2's branch, thenwill regress any changes provided by those commits. This will introduce extra dependencies which incorrectly answer the above question we are trying to answer.
Therefore change the algorithm to only diff against the first parent.
This is very similar in nature to the
-moption ofgit cherry-pick:In the future it may be desirable to add an analogous
-moption to git-deps.Sem-Ver: api-break