>>> 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. I'll combine them then: that seems like the simplest solution. best, - Julia
