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

Hi Julia

On 09/08/2025 02:14, Julia Evans via GitGitGadget wrote:

From: Julia Evans <redacted>

+Here is a more detailed description of what `git rebase <upstream>` does:
+
+First, it makes a list of all commits in the current branch that are not in
+`<upstream>`. This is the same set of commits that would be shown by `git log
+<upstream>..HEAD`.

The existing text is not quite accurate here, it should really say `git 
log --cherry-pick --right-only <upstream>...HEAD` as we drop any commits 
from the branch that have already been cherry-picked to <upstream>.

You can use `--fork-point` or `--root` to change how this
+list of commits is constructed.

`--reapply-cherry-picks` also changes how the list is constructed so I 
think it would be worth adding that option here as well.

Thanks for working on this, it makes the description section much more 
readable.

Phillip

+
+Then it checks out `<upstream>` (or `<newbase>` if the `--onto` option was
+supplied) with the equivalent of `git switch --detach <upstream>`.
+
+Then it replays the commits, one by one, in order. This is similar to running
+`git cherry-pick <commit>` for each commit. See REBASING MERGES for how merges
+are handled.
+
+Finally, it updates your branch to point to the final commit with the equivalent
+of `git switch -C <branch>`.
  
  [NOTE]
+`ORIG_HEAD` is set to point at the tip of the branch before the rebase.
  `ORIG_HEAD` is not guaranteed to still point to the previous branch tip
  at the end of the rebase if other commands that write that pseudo-ref
  (e.g. `git reset`) are used during the rebase. The previous branch tip,
  however, is accessible using the reflog of the current branch
  (i.e. `@{1}`, see linkgit:gitrevisions[7]).
  
-The commits that were previously saved into the temporary area are
-then reapplied to the current branch, one by one, in order. Note that
-any commits in `HEAD` which introduce the same textual changes as a commit
-in `HEAD..<upstream>` are omitted (i.e., a patch already accepted upstream
-with a different commit message or timestamp will be skipped).
-
  If the upstream branch already contains a change you have made (e.g.,
  because you mailed a patch which was applied upstream), then that commit
  will be skipped and warnings will be issued (if the 'merge' backend is