Elijah Newren <newren@xxxxxxxxx> writes: >> And each step in this "rebase" is a 3-way merge of commits A, B and >> C onto HEAD, using the parent of the commit being cherrk-picked as a >> virtual common ancestor. Which means > > You generated nearly the same description and diagram I used in the > commit message (the one in 3/7) describing this. :-) > >> - To transplant A (i.e. the first step), we'd compare the diff of >> A^..O (i.e. what our side did, including the renames done at X) >> and diff of A^..A (i.e. what the first commit did in the range), >> and the former does quite a lot of rename detection. >> >> - After transplanting B (i.e. the second step), then we'd compare >> the diff of A^..A' (where A' is A cherry-picked on O, i.e. the > > Close, but for transplanting B we do the diff of B^..A', not A^...A'. > (And in this diagram, B^ is A.) That's critical below... Yes, I upfront said "pretend that the parent of the commit being picked is the common ancestor and run 3-way merge", but then got confused by the ancestry graph myself, forgetting that the reason why A^ is used in the first "pick" is *not* because the it is the fork point of our history and the side branch, but it is because it is A's parent. And if the renames in B^..A' and A^..A' are different that must have come only from the difference between A..B (which is B^..B), but that comparison is what we do when cherry-picking B on top of A', so it is easy to take into account to reuse the renames precisely without "assuming they are the same". Thanks.
