On 13/08/2025 16:33, Julia Evans wrote:
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.
Possibly though I think they'd need a reasonably good understanding of
how the cherry-pick detection works - do most folks really know what a
patch-id is and that detecting cherry-picks means generating a diff for
each commit on either side of the merge base?
Maybe we could mention that the
`git patch-id` step can be slow in some cases.
That might be worth it depending on how much detail we want. I think it
is only really a problem on large fast-moving repositories where a lot
of upstream commits get added between rebases and on partial clones. The
latter is due to a sub-optimal implementation that does not batch the
fetches for missing blobs, though I guess if your repository is big
enough to warrant a partial clone you'd be likely to hit the first issue
even if the fetching was more efficient. If we say it can be slow we
should perhaps mention that this step can be skipped
(also I might have misunderstood the "fast step" and the "slow step" thing,
I'd be interested to know if so)
I've commented on this in my reply to Junio - I think it depends where
you draw the stop boundaries.
Thanks
Phillip
