Re: [PATCH v6 5/5] doc: git-rebase: update discussion of internals

From: Julia Evans <julia@jvns.ca>
Date: Aug 11, 2025, 22:42 UTC
Message-ID: <fb35edc9-8c90-4a71-9c75-4c83a8f1718f@app.fastmail.com>
In-Reply-To: <xmqqh5ydzf00.fsf@gitster.g>

Show 8 quoted lines

> So, I do not mind #2 described as a separate step.  Conceptually, it
> is between "create a list of all commits in the range and filter out
> what have already been applied" and "create a list of all commits
> that are not in the upstream yet".  We may be able to rephrase "all
> new commits on your current branch" somewhat to make it unnecessary
> to describe #2, though.  If we are willing to stop talking about
> "This is the same set of ...", then the description becomes very
> simple:

To me it feels relevant that `git rebase` is using two separate mechanisms to compare commits: the sha and (I think?) what `git patch-id` does. As a user it feels like an important distinction because normally when I look at my git commits I only use the sha (via something like `git log --graph`) to see what the new commits on a branch are.

Maybe the second part can be rephrased like this to emphasize that it's using a different mechanism than the SHA:

> 2. Check whether any of those commits contain the same changes (according to

   `git patch-id`) as a commit already in `<upstream>` and remove them from
   the list.

> The line is getting overly long here and a few lines below.  If your
> editor has the feature, tell it to auto-wrap at around 66-72 column.

Will fix, and I'll add a pre-commit hook to check for that.

> Force-create-branch while checking out is `git checkout -B
> <branch>`, not -C.

Will fix.