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

From: Julia Evans <julia@jvns.ca>
Date: Aug 13, 2025, 15:33 UTC
Message-ID: <aa1c2758-79f9-47f6-87d4-16b19fa5bd63@app.fastmail.com>
In-Reply-To: <52504ef0-7d4c-4298-af11-10477673e9d0@gmail.com>

Show 5 quoted lines

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

Show 5 quoted lines

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