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.
