doc: git-rebase: update discussion of internals
- make it clearer that we're talking about a multistep process - give a more technically accurate description how rebase works with the merge backend. - condense the explanation of how git rebase skips commits with the same textual changes into a single bullet point and remove the explanatory diagram. Lots of things which are more complicated are already being explained without a diagram. - remove the explanation of how exactly `--fork-point` and `--root` work since that information is in the OPTIONS section - put all discussion of `ORIG_HEAD` inside the note Signed-off-by: Julia Evans <julia@jvns.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Julia Evans committed
Aug 23, 2025 at 00:43 UTC
3f7f2b0359e38a86db601b406d68e8fb43ae977e
1 file changed
+18
-43
Documentation/git-rebase.adoc
+18
-43
@@ -68,51 +68,26 @@ linkgit:git-config[1] for details) and the `--fork-point` option is
68
assumed. If you are currently not on any branch or if the current
69
branch does not have a configured upstream, the rebase will abort.
70
71
-All changes made by commits in the current branch but that are not
72
-in `<upstream>` are saved to a temporary area. This is the same set
73
-of commits that would be shown by `git log <upstream>..HEAD`; or by
74
-`git log 'fork_point'..HEAD`, if `--fork-point` is active (see the
75
-description on `--fork-point` below); or by `git log HEAD`, if the
76
-`--root` option is specified.
77
-
78
-The current branch is reset to `<upstream>` or `<newbase>` if the
79
-`--onto` option was supplied. This has the exact same effect as
80
-`git reset --hard <upstream>` (or `<newbase>`). `ORIG_HEAD` is set
81
-to point at the tip of the branch before the reset.
71
+Here is a simplified description of what `git rebase <upstream>` does:
72
+
73
+1. Make a list of all commits on your current branch since it branched
74
+ off from `<upstream>` that do not have an equivalent commit in
75
+ `<upstream>`.
76
+2. Check out `<upstream>` with the equivalent of
77
+ `git checkout --detach <upstream>`.
78
+3. Replay the commits, one by one, in order. This is similar to running
79
+ `git cherry-pick <commit>` for each commit. See REBASING MERGES for how merges
80
+ are handled.
81
+4. Update your branch to point to the final commit with the equivalent
82
+ of `git checkout -B <branch>`.
83
84
[NOTE]
84
-`ORIG_HEAD` is not guaranteed to still point to the previous branch tip
85
-at the end of the rebase if other commands that write that pseudo-ref
86
-(e.g. `git reset`) are used during the rebase. The previous branch tip,
87
-however, is accessible using the reflog of the current branch
88
-(i.e. `@{1}`, see linkgit:gitrevisions[7]).
89
-
90
-The commits that were previously saved into the temporary area are
91
-then reapplied to the current branch, one by one, in order. Note that
92
-any commits in `HEAD` which introduce the same textual changes as a commit
93
-in `HEAD..<upstream>` are omitted (i.e., a patch already accepted upstream
94
-with a different commit message or timestamp will be skipped).
95
-
96
-If the upstream branch already contains a change you have made (e.g.,
97
-because you mailed a patch which was applied upstream), then that commit
98
-will be skipped and warnings will be issued (if the 'merge' backend is
99
-used). For example, running `git rebase master` on the following
100
-history (in which `A'` and `A` introduce the same set of changes, but
101
-have different committer information):
102
-
103
-------------
104
- A---B---C topic
105
- /
106
- D---E---A'---F master
107
-------------
108
-
109
-will result in:
110
-
111
-------------
112
- B'---C' topic
113
- /
114
- D---E---A'---F master
115
-------------
85
+When starting the rebase, `ORIG_HEAD` is set to point to the commit at the tip
86
+of the to-be-rebased branch. However, `ORIG_HEAD` is not guaranteed to still
87
+point to that commit at the end of the rebase if other commands that change
88
+`ORIG_HEAD` (like `git reset`) are used during the rebase. The previous branch
89
+tip, however, is accessible using the reflog of the current branch (i.e. `@{1}`,
90
+see linkgit:gitrevisions[7].
91
92
TRANSPLANTING A TOPIC BRANCH WITH --ONTO
93
----------------------------------------