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