On 15/08/2025 16:45, Junio C Hamano wrote:
Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
Although the cherry-pick detection happens inside "git log" that
command has a fast step (find the commits on both sides of the merge
base) and a slow step (detect cherry-picks) so I think it depends
where one draws the step boundaries. The cherry-pick detection is
known to be slow when there are a lot of new upstream commits which
was the motivation for adding --reapply-cherry-picks in 0fcb4f6b62
(rebase --merge: optionally skip upstreamed commits, 2020-04-11)
Correct, in the description of "reapply-cherry-picks", it may need
to be discussed to guide the readers decide when to use the option.
But would it really help understanding of readers to give such level
of detail in "here is roughly how it works" description? I am not
sure about that.
I'd certainly be happy to see these two steps in the description
simplified and combined as you've suggested elsewhere.
Thanks
Phillip
