Re: [PATCH v6 0/5] doc: git-rebase: clarify DESCRIPTION section

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