The use case for --reapply-cherry-picks is mostly that it is faster to 
try picking a commit and then drop it if it results in a empty change 
than it is to do the patch-id comparisons to avoid picking the commit in 
the first place. This is especially true on partial clones where the 
cherry-pick detection is really slow.

That makes sense, thank you!

I'm happy to leave it out but I 
wonder if we should drop the references to --fork-point and --root as 
well given they're also both pretty niche. I'd also be very happy to go 
with Junio's suggestion to replace steps 1 & 2 with a general 
description that does not mention 'git log' at all.

I like the idea of leaving out `--fork-point` and `--root`.

Now that I know the use case for `--reapply-cherry-picks`: what I like about
leaving in the `git log` description is that I think it makes it easier for
folks to build a mental model of why a `git rebase` might  be slow: there's a
"fast step" (the `git log` step) and a "slow step" (the `git patch-id` step).
Then even if we don't mention `--reapply-cherry-picks` in this section, a user
could infer that there might be a way to speed up the "slow step", and find the
`--reapply-cherry-picks` option to speed it up. Maybe we could mention that the
`git patch-id` step can be slow in some cases.

(also I might have misunderstood the "fast step" and the "slow step" thing,
I'd be interested to know if so)