Re: [PATCH v4 5/5] doc: git-rebase: update discussion of internals
From: Phillip Wood <hidden>
Date: 2025-08-10 15:42:03
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
quoted hunk ↗ jump to hunk
+ +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