Comment 8 for bug 277537

So way back when, we tried to figure out why parent-order matters for annotate. It turns out that it doesn't in the general case, but it *does* in this specific case because there was a piece of code that was swapped.

Specifically, we have code that looks like:

PARENT 1:
A
B

PARENT 2:
B
C
A

Child:
B
C
A

So the problem seems to be that if you patch against one parent first, you find the match for 'B', and then don't match against A because it is out-of-order.

While if you match against the other parent first, then you match both B and A against the history, and when you match against the other parent, it just considers it introduced in the merge.

Both are valid because of the ambiguity involved in swapping code and a diff algorithm that can only match monotonically increasing lines. (If you have A B => B A, one will be matched and the other will not, but it is somewhat arbitrary which side gets matched.)

It is possible use a diff that can track moved code, though there are still problems. Most notably, if you use the annotation from before the move, how do you note that there *was* a move. As moving a hunk of code is a change to the code base, which should show up somehow in the annotations.

Anyway, by fixing the parent order in the per-file graph, "bzr diff -c XX" will use the same parents as "bzr annotate", which at least will have them agree about what was actually changed in that revision. So while it is arbitrary which we pick, at least post-reconcile both algorithms will make the same arbitrary selection.