Re: [PATCH 0/7] Optimization batch 11: avoid repeatedly detecting same renames

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 25, 2021, 18:59 UTC
Message-ID: <xmqqzgyrukic.fsf@gitster.g>
In-Reply-To: <CABPp-BGMhyn1ricXzx539n-09+BYRHPeruNd4MG2PyQzWaRKow@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 17 quoted lines

>> 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.