Elijah Newren [off-list ref] writes:
quoted
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. :-)
quoted
- 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.
On Thu, Mar 25, 2021 at 12:00 PM Junio C Hamano [off-list ref] wrote:
Elijah Newren [off-list ref] writes:
quoted
quoted
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. :-)
quoted
- 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.
After sending the initial series, I decided to type up a more thorough
document that
* spelled out in more detail how the sequence of cherry-picks work
* proved why the renames in one pick are always a superset of the
renames in the next
* proved why the renames in one pick are _almost_ always also a
rename in the next
* discussed the counterexample cases in more detail, and why the
optimization is still reasonable
I figured the more extended document would be useful in case people
decide to change how things work in the future (e.g. what if someone
wants to turn on break detection?), and wants to be able to check
whether all the conditions and cases still hold.
I then also added details about how things work with directory
renames, in the case that merge.directoryRenames is not the default of
"conflict" (which is trivially handled by stopping and dropping the
cache) but is set to true...and found a case that needed more care due
to interactions with some of the earlier optimizations. (The earlier
optimizations could result in bypassing directory rename detection in
one merge because there was no file added to the old directory, but
the no-directory-rename would be cached for subsequent rebases.)
So I need to get that fixed up and resubmit this series.
On 3/29/2021 6:34 PM, Elijah Newren wrote:...
After sending the initial series, I decided to type up a more thorough
document that
* spelled out in more detail how the sequence of cherry-picks work
* proved why the renames in one pick are always a superset of the
renames in the next
* proved why the renames in one pick are _almost_ always also a
rename in the next
* discussed the counterexample cases in more detail, and why the
optimization is still reasonable
I figured the more extended document would be useful in case people
decide to change how things work in the future (e.g. what if someone
wants to turn on break detection?), and wants to be able to check
whether all the conditions and cases still hold.
I then also added details about how things work with directory
renames, in the case that merge.directoryRenames is not the default of
"conflict" (which is trivially handled by stopping and dropping the
cache) but is set to true...and found a case that needed more care due
to interactions with some of the earlier optimizations. (The earlier
optimizations could result in bypassing directory rename detection in
one merge because there was no file added to the old directory, but
the no-directory-rename would be cached for subsequent rebases.)
So I need to get that fixed up and resubmit this series.
I look forward to that document. I attempted reading this series
yesterday, but did not have the mental energy to convince myself
of the correctness (because of things like not knowing this logic
that you plan to document). Instead, I'll promise to give round 2
a quicker response.
Thanks,
-Stolee