]>
Commit | Line | Data |
---|---|---|
215a7ad1 JH |
1 | git-rebase(1) |
2 | ============= | |
7fc9d69f JH |
3 | |
4 | NAME | |
5 | ---- | |
b385085b | 6 | git-rebase - Reapply commits on top of another base tip |
7fc9d69f JH |
7 | |
8 | SYNOPSIS | |
9 | -------- | |
e448ff87 | 10 | [verse] |
414d924b DL |
11 | 'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] |
12 | [--onto <newbase> | --keep-base] [<upstream> [<branch>]] | |
de613050 | 13 | 'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] |
be496621 | 14 | --root [<branch>] |
437591a9 | 15 | 'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch) |
031321c6 | 16 | |
7fc9d69f JH |
17 | DESCRIPTION |
18 | ----------- | |
0b444cdb | 19 | If <branch> is specified, 'git rebase' will perform an automatic |
328c6cb8 | 20 | `git switch <branch>` before doing anything else. Otherwise |
5ca2db53 SP |
21 | it remains on the current branch. |
22 | ||
15a147e6 | 23 | If <upstream> is not specified, the upstream configured in |
f51a48ec SO |
24 | branch.<name>.remote and branch.<name>.merge options will be used (see |
25 | linkgit:git-config[1] for details) and the `--fork-point` option is | |
26 | assumed. If you are currently not on any branch or if the current | |
27 | branch does not have a configured upstream, the rebase will abort. | |
15a147e6 | 28 | |
5ca2db53 SP |
29 | All changes made by commits in the current branch but that are not |
30 | in <upstream> are saved to a temporary area. This is the same set | |
f51a48ec SO |
31 | of commits that would be shown by `git log <upstream>..HEAD`; or by |
32 | `git log 'fork_point'..HEAD`, if `--fork-point` is active (see the | |
33 | description on `--fork-point` below); or by `git log HEAD`, if the | |
34 | `--root` option is specified. | |
5ca2db53 SP |
35 | |
36 | The current branch is reset to <upstream>, or <newbase> if the | |
37 | --onto option was supplied. This has the exact same effect as | |
9869099b BG |
38 | `git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set |
39 | to point at the tip of the branch before the reset. | |
5ca2db53 SP |
40 | |
41 | The commits that were previously saved into the temporary area are | |
ff905462 JK |
42 | then reapplied to the current branch, one by one, in order. Note that |
43 | any commits in HEAD which introduce the same textual changes as a commit | |
44 | in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream | |
45 | with a different commit message or timestamp will be skipped). | |
69a60af5 | 46 | |
031321c6 SE |
47 | It is possible that a merge failure will prevent this process from being |
48 | completely automatic. You will have to resolve any such merge failure | |
cc120056 | 49 | and run `git rebase --continue`. Another option is to bypass the commit |
5960bc9d | 50 | that caused the merge failure with `git rebase --skip`. To check out the |
51ef1daa JS |
51 | original <branch> and remove the .git/rebase-apply working files, use the |
52 | command `git rebase --abort` instead. | |
031321c6 | 53 | |
69a60af5 CW |
54 | Assume the following history exists and the current branch is "topic": |
55 | ||
031321c6 | 56 | ------------ |
69a60af5 CW |
57 | A---B---C topic |
58 | / | |
59 | D---E---F---G master | |
031321c6 | 60 | ------------ |
69a60af5 | 61 | |
228382ae | 62 | From this point, the result of either of the following commands: |
69a60af5 | 63 | |
031321c6 | 64 | |
b1889c36 JN |
65 | git rebase master |
66 | git rebase master topic | |
69a60af5 CW |
67 | |
68 | would be: | |
69 | ||
031321c6 | 70 | ------------ |
69a60af5 CW |
71 | A'--B'--C' topic |
72 | / | |
73 | D---E---F---G master | |
031321c6 | 74 | ------------ |
69a60af5 | 75 | |
ee55703b DN |
76 | *NOTE:* The latter form is just a short-hand of `git checkout topic` |
77 | followed by `git rebase master`. When rebase exits `topic` will | |
78 | remain the checked-out branch. | |
69a60af5 | 79 | |
ff905462 JK |
80 | If the upstream branch already contains a change you have made (e.g., |
81 | because you mailed a patch which was applied upstream), then that commit | |
767a4ca6 JS |
82 | will be skipped and warnings will be issued (if the `merge` backend is |
83 | used). For example, running `git rebase master` on the following | |
84 | history (in which `A'` and `A` introduce the same set of changes, but | |
85 | have different committer information): | |
ff905462 JK |
86 | |
87 | ------------ | |
88 | A---B---C topic | |
89 | / | |
90 | D---E---A'---F master | |
91 | ------------ | |
92 | ||
93 | will result in: | |
94 | ||
95 | ------------ | |
96 | B'---C' topic | |
97 | / | |
98 | D---E---A'---F master | |
99 | ------------ | |
100 | ||
e52775f4 JN |
101 | Here is how you would transplant a topic branch based on one |
102 | branch to another, to pretend that you forked the topic branch | |
103 | from the latter branch, using `rebase --onto`. | |
69a60af5 | 104 | |
e52775f4 | 105 | First let's assume your 'topic' is based on branch 'next'. |
e2b850b2 | 106 | For example, a feature developed in 'topic' depends on some |
e52775f4 | 107 | functionality which is found in 'next'. |
69a60af5 | 108 | |
031321c6 | 109 | ------------ |
e52775f4 JN |
110 | o---o---o---o---o master |
111 | \ | |
112 | o---o---o---o---o next | |
113 | \ | |
114 | o---o---o topic | |
115 | ------------ | |
116 | ||
e2b850b2 GD |
117 | We want to make 'topic' forked from branch 'master'; for example, |
118 | because the functionality on which 'topic' depends was merged into the | |
119 | more stable 'master' branch. We want our tree to look like this: | |
e52775f4 JN |
120 | |
121 | ------------ | |
122 | o---o---o---o---o master | |
123 | | \ | |
124 | | o'--o'--o' topic | |
125 | \ | |
126 | o---o---o---o---o next | |
031321c6 | 127 | ------------ |
7fc9d69f | 128 | |
e52775f4 JN |
129 | We can get this using the following command: |
130 | ||
b1889c36 | 131 | git rebase --onto master next topic |
e52775f4 JN |
132 | |
133 | ||
134 | Another example of --onto option is to rebase part of a | |
135 | branch. If we have the following situation: | |
136 | ||
137 | ------------ | |
138 | H---I---J topicB | |
139 | / | |
140 | E---F---G topicA | |
141 | / | |
142 | A---B---C---D master | |
143 | ------------ | |
144 | ||
145 | then the command | |
146 | ||
b1889c36 | 147 | git rebase --onto master topicA topicB |
e52775f4 JN |
148 | |
149 | would result in: | |
150 | ||
151 | ------------ | |
152 | H'--I'--J' topicB | |
153 | / | |
154 | | E---F---G topicA | |
155 | |/ | |
156 | A---B---C---D master | |
157 | ------------ | |
158 | ||
159 | This is useful when topicB does not depend on topicA. | |
160 | ||
ea81fcc5 SP |
161 | A range of commits could also be removed with rebase. If we have |
162 | the following situation: | |
163 | ||
164 | ------------ | |
165 | E---F---G---H---I---J topicA | |
166 | ------------ | |
167 | ||
168 | then the command | |
169 | ||
b1889c36 | 170 | git rebase --onto topicA~5 topicA~3 topicA |
ea81fcc5 SP |
171 | |
172 | would result in the removal of commits F and G: | |
173 | ||
174 | ------------ | |
175 | E---H'---I'---J' topicA | |
176 | ------------ | |
177 | ||
178 | This is useful if F and G were flawed in some way, or should not be | |
179 | part of topicA. Note that the argument to --onto and the <upstream> | |
180 | parameter can be any valid commit-ish. | |
181 | ||
0b444cdb TR |
182 | In case of conflict, 'git rebase' will stop at the first problematic commit |
183 | and leave conflict markers in the tree. You can use 'git diff' to locate | |
031321c6 | 184 | the markers (<<<<<<) and make edits to resolve the conflict. For each |
2de9b711 | 185 | file you edit, you need to tell Git that the conflict has been resolved, |
031321c6 SE |
186 | typically this would be done with |
187 | ||
188 | ||
d7f078b8 | 189 | git add <filename> |
031321c6 SE |
190 | |
191 | ||
192 | After resolving the conflict manually and updating the index with the | |
193 | desired resolution, you can continue the rebasing process with | |
194 | ||
195 | ||
196 | git rebase --continue | |
8978d043 | 197 | |
8978d043 | 198 | |
0b444cdb | 199 | Alternatively, you can undo the 'git rebase' with |
8978d043 | 200 | |
031321c6 SE |
201 | |
202 | git rebase --abort | |
8978d043 | 203 | |
7fc9d69f JH |
204 | OPTIONS |
205 | ------- | |
c2145384 | 206 | --onto <newbase>:: |
69a60af5 CW |
207 | Starting point at which to create the new commits. If the |
208 | --onto option is not specified, the starting point is | |
ea81fcc5 SP |
209 | <upstream>. May be any valid commit, and not just an |
210 | existing branch name. | |
873c3472 | 211 | + |
b9190e79 | 212 | As a special case, you may use "A\...B" as a shortcut for the |
873c3472 MG |
213 | merge base of A and B if there is exactly one merge base. You can |
214 | leave out at most one of A and B, in which case it defaults to HEAD. | |
69a60af5 | 215 | |
414d924b DL |
216 | --keep-base:: |
217 | Set the starting point at which to create the new commits to the | |
9e5ebe96 | 218 | merge base of <upstream> and <branch>. Running |
414d924b | 219 | 'git rebase --keep-base <upstream> <branch>' is equivalent to |
9e5ebe96 AH |
220 | running |
221 | 'git rebase --onto <upstream>...<branch> <upstream> <branch>'. | |
414d924b DL |
222 | + |
223 | This option is useful in the case where one is developing a feature on | |
224 | top of an upstream branch. While the feature is being worked on, the | |
225 | upstream branch may advance and it may not be the best idea to keep | |
226 | rebasing on top of the upstream but to keep the base commit as-is. | |
227 | + | |
228 | Although both this option and --fork-point find the merge base between | |
229 | <upstream> and <branch>, this option uses the merge base as the _starting | |
230 | point_ on which new commits will be created, whereas --fork-point uses | |
231 | the merge base to determine the _set of commits_ which will be rebased. | |
232 | + | |
233 | See also INCOMPATIBLE OPTIONS below. | |
234 | ||
52a22d1e | 235 | <upstream>:: |
ea81fcc5 | 236 | Upstream branch to compare against. May be any valid commit, |
15a147e6 MZ |
237 | not just an existing branch name. Defaults to the configured |
238 | upstream for the current branch. | |
7fc9d69f | 239 | |
228382ae | 240 | <branch>:: |
52a22d1e | 241 | Working branch; defaults to HEAD. |
7fc9d69f | 242 | |
031321c6 SE |
243 | --continue:: |
244 | Restart the rebasing process after having resolved a merge conflict. | |
245 | ||
246 | --abort:: | |
5960bc9d MZ |
247 | Abort the rebase operation and reset HEAD to the original |
248 | branch. If <branch> was provided when the rebase operation was | |
249 | started, then HEAD will be reset to <branch>. Otherwise HEAD | |
250 | will be reset to where it was when the rebase operation was | |
251 | started. | |
031321c6 | 252 | |
9512177b NTND |
253 | --quit:: |
254 | Abort the rebase operation but HEAD is not reset back to the | |
255 | original branch. The index and working tree are also left | |
9b2df3e8 | 256 | unchanged as a result. If a temporary stash entry was created |
c5e786ab | 257 | using --autostash, it will be saved to the stash list. |
9512177b | 258 | |
81de0c01 | 259 | --apply:: |
10cdb9f3 EN |
260 | Use applying strategies to rebase (calling `git-am` |
261 | internally). This option may become a no-op in the future | |
262 | once the merge backend handles everything the apply one does. | |
52eb738d EN |
263 | + |
264 | See also INCOMPATIBLE OPTIONS below. | |
265 | ||
e98c4269 EN |
266 | --empty={drop,keep,ask}:: |
267 | How to handle commits that are not empty to start and are not | |
268 | clean cherry-picks of any upstream commit, but which become | |
269 | empty after rebasing (because they contain a subset of already | |
270 | upstream changes). With drop (the default), commits that | |
271 | become empty are dropped. With keep, such commits are kept. | |
272 | With ask (implied by --interactive), the rebase will halt when | |
273 | an empty commit is applied allowing you to choose whether to | |
274 | drop it, edit files more, or just commit the empty changes. | |
275 | Other options, like --exec, will use the default of drop unless | |
276 | -i/--interactive is explicitly specified. | |
277 | + | |
b9cbd295 EN |
278 | Note that commits which start empty are kept (unless --no-keep-empty |
279 | is specified), and commits which are clean cherry-picks (as determined | |
0fcb4f6b JT |
280 | by `git log --cherry-mark ...`) are detected and dropped as a |
281 | preliminary step (unless --reapply-cherry-picks is passed). | |
e98c4269 EN |
282 | + |
283 | See also INCOMPATIBLE OPTIONS below. | |
284 | ||
b9cbd295 | 285 | --no-keep-empty:: |
90e1818f | 286 | --keep-empty:: |
b9cbd295 EN |
287 | Do not keep commits that start empty before the rebase |
288 | (i.e. that do not change anything from its parent) in the | |
289 | result. The default is to keep commits which start empty, | |
290 | since creating such commits requires passing the --allow-empty | |
291 | override flag to `git commit`, signifying that a user is very | |
292 | intentionally creating such a commit and thus wants to keep | |
293 | it. | |
294 | + | |
295 | Usage of this flag will probably be rare, since you can get rid of | |
296 | commits that start empty by just firing up an interactive rebase and | |
297 | removing the lines corresponding to the commits you don't want. This | |
298 | flag exists as a convenient shortcut, such as for cases where external | |
299 | tools generate many empty commits and you want them all removed. | |
300 | + | |
301 | For commits which do not start empty but become empty after rebasing, | |
302 | see the --empty flag. | |
5dacd4ab | 303 | + |
b9cbd295 | 304 | See also INCOMPATIBLE OPTIONS below. |
90e1818f | 305 | |
0fcb4f6b JT |
306 | --reapply-cherry-picks:: |
307 | --no-reapply-cherry-picks:: | |
308 | Reapply all clean cherry-picks of any upstream commit instead | |
309 | of preemptively dropping them. (If these commits then become | |
310 | empty after rebasing, because they contain a subset of already | |
311 | upstream changes, the behavior towards them is controlled by | |
312 | the `--empty` flag.) | |
313 | + | |
314 | By default (or if `--no-reapply-cherry-picks` is given), these commits | |
315 | will be automatically dropped. Because this necessitates reading all | |
316 | upstream commits, this can be expensive in repos with a large number | |
767a4ca6 JS |
317 | of upstream commits that need to be read. When using the `merge` |
318 | backend, warnings will be issued for each dropped commit (unless | |
319 | `--quiet` is given). Advice will also be issued unless | |
320 | `advice.skippedCherryPicks` is set to false (see linkgit:git-config[1]). | |
0fcb4f6b JT |
321 | + |
322 | `--reapply-cherry-picks` allows rebase to forgo reading all upstream | |
323 | commits, potentially improving performance. | |
324 | + | |
325 | See also INCOMPATIBLE OPTIONS below. | |
326 | ||
a6c612b5 | 327 | --allow-empty-message:: |
22a69fda EN |
328 | No-op. Rebasing commits with an empty message used to fail |
329 | and this option would override that behavior, allowing commits | |
330 | with empty messages to be rebased. Now commits with an empty | |
331 | message do not cause rebasing to halt. | |
5dacd4ab EN |
332 | + |
333 | See also INCOMPATIBLE OPTIONS below. | |
a6c612b5 | 334 | |
58634dbf EW |
335 | --skip:: |
336 | Restart the rebasing process by skipping the current patch. | |
58634dbf | 337 | |
eb9a7cb4 AW |
338 | --edit-todo:: |
339 | Edit the todo list during an interactive rebase. | |
340 | ||
66335298 NTND |
341 | --show-current-patch:: |
342 | Show the current patch in an interactive rebase or when rebase | |
fbd7a232 NTND |
343 | is stopped because of conflicts. This is the equivalent of |
344 | `git show REBASE_HEAD`. | |
66335298 | 345 | |
3240240f SB |
346 | -m:: |
347 | --merge:: | |
6320813b | 348 | Using merging strategies to rebase (default). |
31ddd1ee TR |
349 | + |
350 | Note that a rebase merge works by replaying each commit from the working | |
351 | branch on top of the <upstream> branch. Because of this, when a merge | |
352 | conflict happens, the side reported as 'ours' is the so-far rebased | |
353 | series, starting with <upstream>, and 'theirs' is the working branch. In | |
354 | other words, the sides are swapped. | |
5dacd4ab EN |
355 | + |
356 | See also INCOMPATIBLE OPTIONS below. | |
58634dbf | 357 | |
3240240f SB |
358 | -s <strategy>:: |
359 | --strategy=<strategy>:: | |
f5a3c5e6 EN |
360 | Use the given merge strategy, instead of the default `ort`. |
361 | This implies `--merge`. | |
31ddd1ee | 362 | + |
0b444cdb | 363 | Because 'git rebase' replays each commit from the working branch |
31ddd1ee | 364 | on top of the <upstream> branch using the given strategy, using |
5dacd4ab | 365 | the 'ours' strategy simply empties all patches from the <branch>, |
31ddd1ee | 366 | which makes little sense. |
5dacd4ab EN |
367 | + |
368 | See also INCOMPATIBLE OPTIONS below. | |
58634dbf | 369 | |
93ce190c ML |
370 | -X <strategy-option>:: |
371 | --strategy-option=<strategy-option>:: | |
372 | Pass the <strategy-option> through to the merge strategy. | |
6cf378f0 | 373 | This implies `--merge` and, if no strategy has been |
f5a3c5e6 | 374 | specified, `-s ort`. Note the reversal of 'ours' and |
edfbbf7e | 375 | 'theirs' as noted above for the `-m` option. |
5dacd4ab EN |
376 | + |
377 | See also INCOMPATIBLE OPTIONS below. | |
93ce190c | 378 | |
aba4954c PW |
379 | --rerere-autoupdate:: |
380 | --no-rerere-autoupdate:: | |
381 | Allow the rerere mechanism to update the index with the | |
382 | result of auto-conflict resolution if possible. | |
383 | ||
3ee5e540 NV |
384 | -S[<keyid>]:: |
385 | --gpg-sign[=<keyid>]:: | |
c241371c | 386 | --no-gpg-sign:: |
2b594bf9 MM |
387 | GPG-sign commits. The `keyid` argument is optional and |
388 | defaults to the committer identity; if specified, it must be | |
c241371c ĐTCD |
389 | stuck to the option without a space. `--no-gpg-sign` is useful to |
390 | countermand both `commit.gpgSign` configuration variable, and | |
391 | earlier `--gpg-sign`. | |
3ee5e540 | 392 | |
0e987a12 SB |
393 | -q:: |
394 | --quiet:: | |
395 | Be quiet. Implies --no-stat. | |
396 | ||
3240240f SB |
397 | -v:: |
398 | --verbose:: | |
a9c3821c TAV |
399 | Be verbose. Implies --stat. |
400 | ||
401 | --stat:: | |
402 | Show a diffstat of what changed upstream since the last rebase. The | |
403 | diffstat is also controlled by the configuration option rebase.stat. | |
404 | ||
405 | -n:: | |
406 | --no-stat:: | |
407 | Do not show a diffstat as part of the rebase process. | |
b758789c | 408 | |
fd631d58 NS |
409 | --no-verify:: |
410 | This option bypasses the pre-rebase hook. See also linkgit:githooks[5]. | |
411 | ||
7baf9c4b MZ |
412 | --verify:: |
413 | Allows the pre-rebase hook to run, which is the default. This option can | |
414 | be used to override --no-verify. See also linkgit:githooks[5]. | |
415 | ||
67dad687 MT |
416 | -C<n>:: |
417 | Ensure at least <n> lines of surrounding context match before | |
418 | and after each change. When fewer lines of surrounding | |
419 | context exist they all must match. By default no context is | |
10cdb9f3 | 420 | ever ignored. Implies --apply. |
5dacd4ab EN |
421 | + |
422 | See also INCOMPATIBLE OPTIONS below. | |
67dad687 | 423 | |
983f464f | 424 | --no-ff:: |
5e75d56f | 425 | --force-rebase:: |
983f464f EN |
426 | -f:: |
427 | Individually replay all rebased commits instead of fast-forwarding | |
428 | over the unchanged ones. This ensures that the entire history of | |
429 | the rebased branch is composed of new commits. | |
b4995494 | 430 | + |
983f464f EN |
431 | You may find this helpful after reverting a topic branch merge, as this option |
432 | recreates the topic branch with fresh commits so it can be remerged | |
433 | successfully without needing to "revert the reversion" (see the | |
434 | link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for | |
435 | details). | |
5e75d56f | 436 | |
ad8261d2 JK |
437 | --fork-point:: |
438 | --no-fork-point:: | |
f51a48ec SO |
439 | Use reflog to find a better common ancestor between <upstream> |
440 | and <branch> when calculating which commits have been | |
441 | introduced by <branch>. | |
ad8261d2 | 442 | + |
f51a48ec SO |
443 | When --fork-point is active, 'fork_point' will be used instead of |
444 | <upstream> to calculate the set of commits to rebase, where | |
445 | 'fork_point' is the result of `git merge-base --fork-point <upstream> | |
446 | <branch>` command (see linkgit:git-merge-base[1]). If 'fork_point' | |
447 | ends up being empty, the <upstream> will be used as a fallback. | |
448 | + | |
a35413c3 | 449 | If <upstream> is given on the command line, then the default is |
d1e894c6 WS |
450 | `--no-fork-point`, otherwise the default is `--fork-point`. See also |
451 | `rebase.forkpoint` in linkgit:git-config[1]. | |
414d924b DL |
452 | + |
453 | If your branch was based on <upstream> but <upstream> was rewound and | |
454 | your branch contains commits which were dropped, this option can be used | |
455 | with `--keep-base` in order to drop those commits from your branch. | |
a35413c3 EN |
456 | + |
457 | See also INCOMPATIBLE OPTIONS below. | |
ad8261d2 | 458 | |
86c91f91 | 459 | --ignore-whitespace:: |
ef484add RA |
460 | Ignore whitespace differences when trying to reconcile |
461 | differences. Currently, each backend implements an approximation of | |
462 | this behavior: | |
463 | + | |
464 | apply backend: When applying a patch, ignore changes in whitespace in | |
465 | context lines. Unfortunately, this means that if the "old" lines being | |
466 | replaced by the patch differ only in whitespace from the existing | |
467 | file, you will get a merge conflict instead of a successful patch | |
468 | application. | |
469 | + | |
470 | merge backend: Treat lines with only whitespace changes as unchanged | |
471 | when merging. Unfortunately, this means that any patch hunks that were | |
472 | intended to modify whitespace and nothing else will be dropped, even | |
473 | if the other side had no changes that conflicted. | |
474 | ||
749485f6 | 475 | --whitespace=<option>:: |
ef484add | 476 | This flag is passed to the 'git apply' program |
5162e697 | 477 | (see linkgit:git-apply[1]) that applies the patch. |
10cdb9f3 | 478 | Implies --apply. |
5dacd4ab EN |
479 | + |
480 | See also INCOMPATIBLE OPTIONS below. | |
059f446d | 481 | |
570ccad3 | 482 | --committer-date-is-author-date:: |
7573cec5 PW |
483 | Instead of using the current time as the committer date, use |
484 | the author date of the commit being rebased as the committer | |
485 | date. This option implies `--force-rebase`. | |
486 | ||
570ccad3 | 487 | --ignore-date:: |
27126692 | 488 | --reset-author-date:: |
a3894aad PW |
489 | Instead of using the author date of the original commit, use |
490 | the current time as the author date of the rebased commit. This | |
491 | option implies `--force-rebase`. | |
5dacd4ab EN |
492 | + |
493 | See also INCOMPATIBLE OPTIONS below. | |
570ccad3 | 494 | |
9f79524a | 495 | --signoff:: |
3abd4a67 | 496 | Add a `Signed-off-by` trailer to all the rebased commits. Note |
a852ec7f | 497 | that if `--interactive` is given then only commits marked to be |
5dacd4ab EN |
498 | picked, edited or reworded will have the trailer added. |
499 | + | |
500 | See also INCOMPATIBLE OPTIONS below. | |
9f79524a | 501 | |
3240240f SB |
502 | -i:: |
503 | --interactive:: | |
1b1dce4b | 504 | Make a list of the commits which are about to be rebased. Let the |
f0fd889d JS |
505 | user edit that list before rebasing. This mode can also be used to |
506 | split commits (see SPLITTING COMMITS below). | |
16cf51c7 MR |
507 | + |
508 | The commit list format can be changed by setting the configuration option | |
509 | rebase.instructionFormat. A customized instruction format will automatically | |
510 | have the long commit hash prepended to the format. | |
5dacd4ab EN |
511 | + |
512 | See also INCOMPATIBLE OPTIONS below. | |
1b1dce4b | 513 | |
8f6aed71 | 514 | -r:: |
7543f6f4 | 515 | --rebase-merges[=(rebase-cousins|no-rebase-cousins)]:: |
8f6aed71 JS |
516 | By default, a rebase will simply drop merge commits from the todo |
517 | list, and put the rebased commits into a single, linear branch. | |
518 | With `--rebase-merges`, the rebase will instead try to preserve | |
519 | the branching structure within the commits that are to be rebased, | |
520 | by recreating the merge commits. Any resolved merge conflicts or | |
521 | manual amendments in these merge commits will have to be | |
522 | resolved/re-applied manually. | |
523 | + | |
7543f6f4 JS |
524 | By default, or when `no-rebase-cousins` was specified, commits which do not |
525 | have `<upstream>` as direct ancestor will keep their original branch point, | |
dbf47215 | 526 | i.e. commits that would be excluded by linkgit:git-log[1]'s |
7543f6f4 JS |
527 | `--ancestry-path` option will keep their original ancestry by default. If |
528 | the `rebase-cousins` mode is turned on, such commits are instead rebased | |
529 | onto `<upstream>` (or `<onto>`, if specified). | |
530 | + | |
8f6aed71 | 531 | It is currently only possible to recreate the merge commits using the |
f5a3c5e6 | 532 | `ort` merge strategy; different merge strategies can be used only via |
8f6aed71 | 533 | explicit `exec git merge -s <strategy> [...]` commands. |
25cff9f1 | 534 | + |
5dacd4ab | 535 | See also REBASING MERGES and INCOMPATIBLE OPTIONS below. |
8f6aed71 | 536 | |
c2145384 LK |
537 | -x <cmd>:: |
538 | --exec <cmd>:: | |
539 | Append "exec <cmd>" after each line creating a commit in the | |
540 | final history. <cmd> will be interpreted as one or more shell | |
b8c0b210 JS |
541 | commands. Any command that fails will interrupt the rebase, |
542 | with exit code 1. | |
c2145384 | 543 | + |
c2145384 LK |
544 | You may execute several commands by either using one instance of `--exec` |
545 | with several commands: | |
546 | + | |
547 | git rebase -i --exec "cmd1 && cmd2 && ..." | |
548 | + | |
549 | or by giving more than one `--exec`: | |
550 | + | |
551 | git rebase -i --exec "cmd1" --exec "cmd2" --exec ... | |
552 | + | |
553 | If `--autosquash` is used, "exec" lines will not be appended for | |
554 | the intermediate commits, and will only appear at the end of each | |
555 | squash/fixup series. | |
78ec2400 SB |
556 | + |
557 | This uses the `--interactive` machinery internally, but it can be run | |
558 | without an explicit `--interactive`. | |
5dacd4ab EN |
559 | + |
560 | See also INCOMPATIBLE OPTIONS below. | |
f09c9b8c | 561 | |
be496621 TR |
562 | --root:: |
563 | Rebase all commits reachable from <branch>, instead of | |
564 | limiting them with an <upstream>. This allows you to rebase | |
df5df20c | 565 | the root commit(s) on a branch. When used with --onto, it |
be496621 | 566 | will skip changes already contained in <newbase> (instead of |
df5df20c | 567 | <upstream>) whereas without --onto it will operate on every change. |
5dacd4ab EN |
568 | + |
569 | See also INCOMPATIBLE OPTIONS below. | |
be496621 | 570 | |
f59baa50 | 571 | --autosquash:: |
dd1e5b31 | 572 | --no-autosquash:: |
00ea64ed CM |
573 | When the commit log message begins with "squash! ..." or "fixup! ..." |
574 | or "amend! ...", and there is already a commit in the todo list that | |
575 | matches the same `...`, automatically modify the todo list of | |
576 | `rebase -i`, so that the commit marked for squashing comes right after | |
577 | the commit to be modified, and change the action of the moved commit | |
578 | from `pick` to `squash` or `fixup` or `fixup -C` respectively. A commit | |
579 | matches the `...` if the commit subject matches, or if the `...` refers | |
580 | to the commit's hash. As a fall-back, partial matches of the commit | |
581 | subject work, too. The recommended way to create fixup/amend/squash | |
582 | commits is by using the `--fixup`, `--fixup=amend:` or `--fixup=reword:` | |
583 | and `--squash` options respectively of linkgit:git-commit[1]. | |
f59baa50 | 584 | + |
bcf9626a | 585 | If the `--autosquash` option is enabled by default using the |
da0005b8 | 586 | configuration variable `rebase.autoSquash`, this option can be |
dd1e5b31 | 587 | used to override and disable this setting. |
5dacd4ab EN |
588 | + |
589 | See also INCOMPATIBLE OPTIONS below. | |
b4995494 | 590 | |
82e0668c JK |
591 | --autostash:: |
592 | --no-autostash:: | |
e01db917 | 593 | Automatically create a temporary stash entry before the operation |
58794775 RR |
594 | begins, and apply it after the operation ends. This means |
595 | that you can run rebase on a dirty worktree. However, use | |
596 | with care: the final stash application after a successful | |
597 | rebase might result in non-trivial conflicts. | |
598 | ||
d421afa0 JS |
599 | --reschedule-failed-exec:: |
600 | --no-reschedule-failed-exec:: | |
601 | Automatically reschedule `exec` commands that failed. This only makes | |
602 | sense in interactive mode (or when an `--exec` option was provided). | |
e5b32bff ÆAB |
603 | + |
604 | Even though this option applies once a rebase is started, it's set for | |
605 | the whole rebase at the start based on either the | |
606 | `rebase.rescheduleFailedExec` configuration (see linkgit:git-config[1] | |
607 | or "CONFIGURATION" below) or whether this option is | |
608 | provided. Otherwise an explicit `--no-reschedule-failed-exec` at the | |
609 | start would be overridden by the presence of | |
610 | `rebase.rescheduleFailedExec=true` configuration. | |
d421afa0 | 611 | |
5dacd4ab EN |
612 | INCOMPATIBLE OPTIONS |
613 | -------------------- | |
614 | ||
68aa495b | 615 | The following options: |
5dacd4ab | 616 | |
10cdb9f3 | 617 | * --apply |
be50c938 | 618 | * --whitespace |
5dacd4ab EN |
619 | * -C |
620 | ||
68aa495b | 621 | are incompatible with the following options: |
5dacd4ab EN |
622 | |
623 | * --merge | |
624 | * --strategy | |
625 | * --strategy-option | |
626 | * --allow-empty-message | |
5dacd4ab EN |
627 | * --[no-]autosquash |
628 | * --rebase-merges | |
5dacd4ab EN |
629 | * --interactive |
630 | * --exec | |
b9cbd295 | 631 | * --no-keep-empty |
e98c4269 | 632 | * --empty= |
0fcb4f6b | 633 | * --reapply-cherry-picks |
5dacd4ab EN |
634 | * --edit-todo |
635 | * --root when used in combination with --onto | |
636 | ||
68aa495b | 637 | In addition, the following pairs of options are incompatible: |
5dacd4ab | 638 | |
414d924b DL |
639 | * --keep-base and --onto |
640 | * --keep-base and --root | |
a35413c3 | 641 | * --fork-point and --root |
5dacd4ab | 642 | |
0661e49a EN |
643 | BEHAVIORAL DIFFERENCES |
644 | ----------------------- | |
645 | ||
10cdb9f3 | 646 | git rebase has two primary backends: apply and merge. (The apply |
344420bf | 647 | backend used to be known as the 'am' backend, but the name led to |
10cdb9f3 EN |
648 | confusion as it looks like a verb instead of a noun. Also, the merge |
649 | backend used to be known as the interactive backend, but it is now | |
650 | used for non-interactive cases as well. Both were renamed based on | |
651 | lower-level functionality that underpinned each.) There are some | |
652 | subtle differences in how these two backends behave: | |
0661e49a | 653 | |
6fcbad87 JS |
654 | Empty commits |
655 | ~~~~~~~~~~~~~ | |
0661e49a | 656 | |
10cdb9f3 | 657 | The apply backend unfortunately drops intentionally empty commits, i.e. |
d48e5e21 EN |
658 | commits that started empty, though these are rare in practice. It |
659 | also drops commits that become empty and has no option for controlling | |
660 | this behavior. | |
0661e49a | 661 | |
b9cbd295 EN |
662 | The merge backend keeps intentionally empty commits by default (though |
663 | with -i they are marked as empty in the todo list editor, or they can | |
664 | be dropped automatically with --no-keep-empty). | |
665 | ||
666 | Similar to the apply backend, by default the merge backend drops | |
667 | commits that become empty unless -i/--interactive is specified (in | |
668 | which case it stops and asks the user what to do). The merge backend | |
669 | also has an --empty={drop,keep,ask} option for changing the behavior | |
670 | of handling commits that become empty. | |
0661e49a | 671 | |
6fcbad87 JS |
672 | Directory rename detection |
673 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
674 | ||
be50c938 EN |
675 | Due to the lack of accurate tree information (arising from |
676 | constructing fake ancestors with the limited information available in | |
10cdb9f3 | 677 | patches), directory rename detection is disabled in the apply backend. |
be50c938 EN |
678 | Disabled directory rename detection means that if one side of history |
679 | renames a directory and the other adds new files to the old directory, | |
680 | then the new files will be left behind in the old directory without | |
681 | any warning at the time of rebasing that you may want to move these | |
682 | files into the new directory. | |
683 | ||
10cdb9f3 EN |
684 | Directory rename detection works with the merge backend to provide you |
685 | warnings in such cases. | |
be50c938 EN |
686 | |
687 | Context | |
688 | ~~~~~~~ | |
689 | ||
10cdb9f3 | 690 | The apply backend works by creating a sequence of patches (by calling |
be50c938 EN |
691 | `format-patch` internally), and then applying the patches in sequence |
692 | (calling `am` internally). Patches are composed of multiple hunks, | |
693 | each with line numbers, a context region, and the actual changes. The | |
694 | line numbers have to be taken with some fuzz, since the other side | |
695 | will likely have inserted or deleted lines earlier in the file. The | |
696 | context region is meant to help find how to adjust the line numbers in | |
697 | order to apply the changes to the right lines. However, if multiple | |
698 | areas of the code have the same surrounding lines of context, the | |
699 | wrong one can be picked. There are real-world cases where this has | |
700 | caused commits to be reapplied incorrectly with no conflicts reported. | |
701 | Setting diff.context to a larger value may prevent such types of | |
702 | problems, but increases the chance of spurious conflicts (since it | |
703 | will require more lines of matching context to apply). | |
704 | ||
10cdb9f3 | 705 | The merge backend works with a full copy of each relevant file, |
be50c938 EN |
706 | insulating it from these types of problems. |
707 | ||
708 | Labelling of conflicts markers | |
709 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
710 | ||
711 | When there are content conflicts, the merge machinery tries to | |
712 | annotate each side's conflict markers with the commits where the | |
10cdb9f3 | 713 | content came from. Since the apply backend drops the original |
be50c938 EN |
714 | information about the rebased commits and their parents (and instead |
715 | generates new fake commits based off limited information in the | |
716 | generated patches), those commits cannot be identified; instead it has | |
717 | to fall back to a commit summary. Also, when merge.conflictStyle is | |
ddfc44a8 EN |
718 | set to diff3 or zdiff3, the apply backend will use "constructed merge |
719 | base" to label the content from the merge base, and thus provide no | |
720 | information about the merge base commit whatsoever. | |
be50c938 | 721 | |
10cdb9f3 EN |
722 | The merge backend works with the full commits on both sides of history |
723 | and thus has no such limitations. | |
be50c938 EN |
724 | |
725 | Hooks | |
726 | ~~~~~ | |
727 | ||
10cdb9f3 | 728 | The apply backend has not traditionally called the post-commit hook, |
f7139e7c EN |
729 | while the merge backend has. Both have called the post-checkout hook, |
730 | though the merge backend has squelched its output. Further, both | |
731 | backends only call the post-checkout hook with the starting point | |
732 | commit of the rebase, not the intermediate commits nor the final | |
733 | commit. In each case, the calling of these hooks was by accident of | |
734 | implementation rather than by design (both backends were originally | |
735 | implemented as shell scripts and happened to invoke other commands | |
736 | like 'git checkout' or 'git commit' that would call the hooks). Both | |
737 | backends should have the same behavior, though it is not entirely | |
738 | clear which, if any, is correct. We will likely make rebase stop | |
739 | calling either of these hooks in the future. | |
be50c938 | 740 | |
2ac0d627 EN |
741 | Interruptability |
742 | ~~~~~~~~~~~~~~~~ | |
743 | ||
10cdb9f3 EN |
744 | The apply backend has safety problems with an ill-timed interrupt; if |
745 | the user presses Ctrl-C at the wrong time to try to abort the rebase, | |
746 | the rebase can enter a state where it cannot be aborted with a | |
747 | subsequent `git rebase --abort`. The merge backend does not appear to | |
2ac0d627 EN |
748 | suffer from the same shortcoming. (See |
749 | https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/ for | |
750 | details.) | |
751 | ||
120b1eb7 EN |
752 | Commit Rewording |
753 | ~~~~~~~~~~~~~~~~ | |
754 | ||
755 | When a conflict occurs while rebasing, rebase stops and asks the user | |
756 | to resolve. Since the user may need to make notable changes while | |
757 | resolving conflicts, after conflicts are resolved and the user has run | |
758 | `git rebase --continue`, the rebase should open an editor and ask the | |
759 | user to update the commit message. The merge backend does this, while | |
760 | the apply backend blindly applies the original commit message. | |
761 | ||
be50c938 EN |
762 | Miscellaneous differences |
763 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
764 | ||
765 | There are a few more behavioral differences that most folks would | |
766 | probably consider inconsequential but which are mentioned for | |
767 | completeness: | |
768 | ||
769 | * Reflog: The two backends will use different wording when describing | |
770 | the changes made in the reflog, though both will make use of the | |
771 | word "rebase". | |
772 | ||
773 | * Progress, informational, and error messages: The two backends | |
774 | provide slightly different progress and informational messages. | |
10cdb9f3 EN |
775 | Also, the apply backend writes error messages (such as "Your files |
776 | would be overwritten...") to stdout, while the merge backend writes | |
777 | them to stderr. | |
be50c938 EN |
778 | |
779 | * State directories: The two backends keep their state in different | |
780 | directories under .git/ | |
f59baa50 | 781 | |
58634dbf EW |
782 | include::merge-strategies.txt[] |
783 | ||
031321c6 SE |
784 | NOTES |
785 | ----- | |
90d1c08e | 786 | |
0b444cdb | 787 | You should understand the implications of using 'git rebase' on a |
90d1c08e TR |
788 | repository that you share. See also RECOVERING FROM UPSTREAM REBASE |
789 | below. | |
031321c6 | 790 | |
467c0197 | 791 | When the git-rebase command is run, it will first execute a "pre-rebase" |
031321c6 SE |
792 | hook if one exists. You can use this hook to do sanity checks and |
793 | reject the rebase if it isn't appropriate. Please see the template | |
794 | pre-rebase hook script for an example. | |
795 | ||
702088af | 796 | Upon completion, <branch> will be the current branch. |
031321c6 | 797 | |
1b1dce4b JS |
798 | INTERACTIVE MODE |
799 | ---------------- | |
800 | ||
801 | Rebasing interactively means that you have a chance to edit the commits | |
802 | which are rebased. You can reorder the commits, and you can | |
803 | remove them (weeding out bad or otherwise unwanted patches). | |
804 | ||
805 | The interactive mode is meant for this type of workflow: | |
806 | ||
807 | 1. have a wonderful idea | |
808 | 2. hack on the code | |
809 | 3. prepare a series for submission | |
810 | 4. submit | |
811 | ||
812 | where point 2. consists of several instances of | |
813 | ||
d3f2475c NBL |
814 | a) regular use |
815 | ||
1b1dce4b JS |
816 | 1. finish something worthy of a commit |
817 | 2. commit | |
d3f2475c NBL |
818 | |
819 | b) independent fixup | |
820 | ||
1b1dce4b JS |
821 | 1. realize that something does not work |
822 | 2. fix that | |
823 | 3. commit it | |
824 | ||
825 | Sometimes the thing fixed in b.2. cannot be amended to the not-quite | |
826 | perfect commit it fixes, because that commit is buried deeply in a | |
827 | patch series. That is exactly what interactive rebase is for: use it | |
828 | after plenty of "a"s and "b"s, by rearranging and editing | |
829 | commits, and squashing multiple commits into one. | |
830 | ||
831 | Start it with the last commit you want to retain as-is: | |
832 | ||
833 | git rebase -i <after-this-commit> | |
834 | ||
835 | An editor will be fired up with all the commits in your current branch | |
836 | (ignoring merge commits), which come after the given commit. You can | |
837 | reorder the commits in this list to your heart's content, and you can | |
838 | remove them. The list looks more or less like this: | |
839 | ||
840 | ------------------------------------------- | |
841 | pick deadbee The oneline of this commit | |
842 | pick fa1afe1 The oneline of the next commit | |
843 | ... | |
844 | ------------------------------------------- | |
845 | ||
0b444cdb | 846 | The oneline descriptions are purely for your pleasure; 'git rebase' will |
1b1dce4b JS |
847 | not look at them but at the commit names ("deadbee" and "fa1afe1" in this |
848 | example), so do not delete or edit the names. | |
849 | ||
850 | By replacing the command "pick" with the command "edit", you can tell | |
0b444cdb | 851 | 'git rebase' to stop after applying that commit, so that you can edit |
1b1dce4b JS |
852 | the files and/or the commit message, amend the commit, and continue |
853 | rebasing. | |
854 | ||
71f82465 JS |
855 | To interrupt the rebase (just like an "edit" command would do, but without |
856 | cherry-picking any commit first), use the "break" command. | |
857 | ||
6741aa6c BG |
858 | If you just want to edit the commit message for a commit, replace the |
859 | command "pick" with the command "reword". | |
860 | ||
c9266d58 GR |
861 | To drop a commit, replace the command "pick" with "drop", or just |
862 | delete the matching line. | |
863 | ||
1b1dce4b | 864 | If you want to fold two or more commits into one, replace the command |
0205e72f MH |
865 | "pick" for the second and subsequent commits with "squash" or "fixup". |
866 | If the commits had different authors, the folded commit will be | |
867 | attributed to the author of the first commit. The suggested commit | |
2c0aa2ce CM |
868 | message for the folded commit is the concatenation of the first |
869 | commit's message with those identified by "squash" commands, omitting the | |
870 | messages of commits identified by "fixup" commands, unless "fixup -c" | |
871 | is used. In that case the suggested commit message is only the message | |
872 | of the "fixup -c" commit, and an editor is opened allowing you to edit | |
873 | the message. The contents (patch) of the "fixup -c" commit are still | |
874 | incorporated into the folded commit. If there is more than one "fixup -c" | |
fa153c1c | 875 | commit, the message from the final one is used. You can also use |
2c0aa2ce CM |
876 | "fixup -C" to get the same behavior as "fixup -c" except without opening |
877 | an editor. | |
878 | ||
1b1dce4b | 879 | |
0b444cdb | 880 | 'git rebase' will stop when "pick" has been replaced with "edit" or |
6741aa6c BG |
881 | when a command fails due to merge errors. When you are done editing |
882 | and/or resolving conflicts you can continue with `git rebase --continue`. | |
1b1dce4b JS |
883 | |
884 | For example, if you want to reorder the last 5 commits, such that what | |
885 | was HEAD~4 becomes the new HEAD. To achieve that, you would call | |
0b444cdb | 886 | 'git rebase' like this: |
1b1dce4b JS |
887 | |
888 | ---------------------- | |
889 | $ git rebase -i HEAD~5 | |
890 | ---------------------- | |
891 | ||
892 | And move the first patch to the end of the list. | |
893 | ||
7948b49a JS |
894 | You might want to recreate merge commits, e.g. if you have a history |
895 | like this: | |
f09c9b8c JS |
896 | |
897 | ------------------ | |
898 | X | |
899 | \ | |
900 | A---M---B | |
901 | / | |
902 | ---o---O---P---Q | |
903 | ------------------ | |
904 | ||
905 | Suppose you want to rebase the side branch starting at "A" to "Q". Make | |
906 | sure that the current HEAD is "B", and call | |
907 | ||
908 | ----------------------------- | |
7948b49a | 909 | $ git rebase -i -r --onto Q O |
f09c9b8c JS |
910 | ----------------------------- |
911 | ||
cd035b1c MM |
912 | Reordering and editing commits usually creates untested intermediate |
913 | steps. You may want to check that your history editing did not break | |
914 | anything by running a test, or at least recompiling at intermediate | |
915 | points in history by using the "exec" command (shortcut "x"). You may | |
916 | do so by creating a todo list like this one: | |
917 | ||
918 | ------------------------------------------- | |
919 | pick deadbee Implement feature XXX | |
920 | fixup f1a5c00 Fix to feature XXX | |
921 | exec make | |
922 | pick c0ffeee The oneline of the next commit | |
923 | edit deadbab The oneline of the commit after | |
924 | exec cd subdir; make test | |
925 | ... | |
926 | ------------------------------------------- | |
927 | ||
928 | The interactive rebase will stop when a command fails (i.e. exits with | |
929 | non-0 status) to give you an opportunity to fix the problem. You can | |
930 | continue with `git rebase --continue`. | |
931 | ||
932 | The "exec" command launches the command in a shell (the one specified | |
933 | in `$SHELL`, or the default shell if `$SHELL` is not set), so you can | |
934 | use shell features (like "cd", ">", ";" ...). The command is run from | |
935 | the root of the working tree. | |
f0fd889d | 936 | |
c2145384 LK |
937 | ---------------------------------- |
938 | $ git rebase -i --exec "make test" | |
939 | ---------------------------------- | |
940 | ||
941 | This command lets you check that intermediate commits are compilable. | |
942 | The todo list becomes like that: | |
943 | ||
944 | -------------------- | |
945 | pick 5928aea one | |
946 | exec make test | |
947 | pick 04d0fda two | |
948 | exec make test | |
949 | pick ba46169 three | |
950 | exec make test | |
951 | pick f4593f9 four | |
952 | exec make test | |
953 | -------------------- | |
954 | ||
f0fd889d JS |
955 | SPLITTING COMMITS |
956 | ----------------- | |
957 | ||
958 | In interactive mode, you can mark commits with the action "edit". However, | |
0b444cdb | 959 | this does not necessarily mean that 'git rebase' expects the result of this |
f0fd889d JS |
960 | edit to be exactly one commit. Indeed, you can undo the commit, or you can |
961 | add other commits. This can be used to split a commit into two: | |
962 | ||
483bc4f0 | 963 | - Start an interactive rebase with `git rebase -i <commit>^`, where |
f0fd889d JS |
964 | <commit> is the commit you want to split. In fact, any commit range |
965 | will do, as long as it contains that commit. | |
966 | ||
967 | - Mark the commit you want to split with the action "edit". | |
968 | ||
483bc4f0 | 969 | - When it comes to editing that commit, execute `git reset HEAD^`. The |
f0fd889d JS |
970 | effect is that the HEAD is rewound by one, and the index follows suit. |
971 | However, the working tree stays the same. | |
972 | ||
973 | - Now add the changes to the index that you want to have in the first | |
483bc4f0 | 974 | commit. You can use `git add` (possibly interactively) or |
0b444cdb | 975 | 'git gui' (or both) to do that. |
f0fd889d JS |
976 | |
977 | - Commit the now-current index with whatever commit message is appropriate | |
978 | now. | |
979 | ||
980 | - Repeat the last two steps until your working tree is clean. | |
981 | ||
483bc4f0 | 982 | - Continue the rebase with `git rebase --continue`. |
f0fd889d JS |
983 | |
984 | If you are not absolutely sure that the intermediate revisions are | |
985 | consistent (they compile, pass the testsuite, etc.) you should use | |
0b444cdb | 986 | 'git stash' to stash away the not-yet-committed changes |
f0fd889d JS |
987 | after each commit, test, and amend the commit if fixes are necessary. |
988 | ||
989 | ||
90d1c08e TR |
990 | RECOVERING FROM UPSTREAM REBASE |
991 | ------------------------------- | |
992 | ||
993 | Rebasing (or any other form of rewriting) a branch that others have | |
994 | based work on is a bad idea: anyone downstream of it is forced to | |
995 | manually fix their history. This section explains how to do the fix | |
996 | from the downstream's point of view. The real fix, however, would be | |
997 | to avoid rebasing the upstream in the first place. | |
998 | ||
999 | To illustrate, suppose you are in a situation where someone develops a | |
1000 | 'subsystem' branch, and you are working on a 'topic' that is dependent | |
1001 | on this 'subsystem'. You might end up with a history like the | |
1002 | following: | |
1003 | ||
1004 | ------------ | |
01826066 | 1005 | o---o---o---o---o---o---o---o master |
90d1c08e TR |
1006 | \ |
1007 | o---o---o---o---o subsystem | |
1008 | \ | |
1009 | *---*---* topic | |
1010 | ------------ | |
1011 | ||
1012 | If 'subsystem' is rebased against 'master', the following happens: | |
1013 | ||
1014 | ------------ | |
1015 | o---o---o---o---o---o---o---o master | |
1016 | \ \ | |
1017 | o---o---o---o---o o'--o'--o'--o'--o' subsystem | |
1018 | \ | |
1019 | *---*---* topic | |
1020 | ------------ | |
1021 | ||
1022 | If you now continue development as usual, and eventually merge 'topic' | |
1023 | to 'subsystem', the commits from 'subsystem' will remain duplicated forever: | |
1024 | ||
1025 | ------------ | |
1026 | o---o---o---o---o---o---o---o master | |
1027 | \ \ | |
1028 | o---o---o---o---o o'--o'--o'--o'--o'--M subsystem | |
1029 | \ / | |
1030 | *---*---*-..........-*--* topic | |
1031 | ------------ | |
1032 | ||
1033 | Such duplicates are generally frowned upon because they clutter up | |
1034 | history, making it harder to follow. To clean things up, you need to | |
1035 | transplant the commits on 'topic' to the new 'subsystem' tip, i.e., | |
1036 | rebase 'topic'. This becomes a ripple effect: anyone downstream from | |
1037 | 'topic' is forced to rebase too, and so on! | |
1038 | ||
1039 | There are two kinds of fixes, discussed in the following subsections: | |
1040 | ||
1041 | Easy case: The changes are literally the same.:: | |
1042 | ||
1043 | This happens if the 'subsystem' rebase was a simple rebase and | |
1044 | had no conflicts. | |
1045 | ||
1046 | Hard case: The changes are not the same.:: | |
1047 | ||
1048 | This happens if the 'subsystem' rebase had conflicts, or used | |
6cf378f0 JK |
1049 | `--interactive` to omit, edit, squash, or fixup commits; or |
1050 | if the upstream used one of `commit --amend`, `reset`, or | |
9df53c5d EN |
1051 | a full history rewriting command like |
1052 | https://github.com/newren/git-filter-repo[`filter-repo`]. | |
90d1c08e TR |
1053 | |
1054 | ||
1055 | The easy case | |
1056 | ~~~~~~~~~~~~~ | |
1057 | ||
1058 | Only works if the changes (patch IDs based on the diff contents) on | |
1059 | 'subsystem' are literally the same before and after the rebase | |
1060 | 'subsystem' did. | |
1061 | ||
0b444cdb | 1062 | In that case, the fix is easy because 'git rebase' knows to skip |
0fcb4f6b JT |
1063 | changes that are already present in the new upstream (unless |
1064 | `--reapply-cherry-picks` is given). So if you say | |
90d1c08e TR |
1065 | (assuming you're on 'topic') |
1066 | ------------ | |
1067 | $ git rebase subsystem | |
1068 | ------------ | |
1069 | you will end up with the fixed history | |
1070 | ------------ | |
1071 | o---o---o---o---o---o---o---o master | |
1072 | \ | |
1073 | o'--o'--o'--o'--o' subsystem | |
1074 | \ | |
1075 | *---*---* topic | |
1076 | ------------ | |
1077 | ||
1078 | ||
1079 | The hard case | |
1080 | ~~~~~~~~~~~~~ | |
1081 | ||
1082 | Things get more complicated if the 'subsystem' changes do not exactly | |
1083 | correspond to the ones before the rebase. | |
1084 | ||
1085 | NOTE: While an "easy case recovery" sometimes appears to be successful | |
1086 | even in the hard case, it may have unintended consequences. For | |
1087 | example, a commit that was removed via `git rebase | |
6cf378f0 | 1088 | --interactive` will be **resurrected**! |
90d1c08e | 1089 | |
0b444cdb | 1090 | The idea is to manually tell 'git rebase' "where the old 'subsystem' |
414d924b | 1091 | ended and your 'topic' began", that is, what the old merge base |
90d1c08e TR |
1092 | between them was. You will have to find a way to name the last commit |
1093 | of the old 'subsystem', for example: | |
1094 | ||
0b444cdb | 1095 | * With the 'subsystem' reflog: after 'git fetch', the old tip of |
6cf378f0 | 1096 | 'subsystem' is at `subsystem@{1}`. Subsequent fetches will |
90d1c08e TR |
1097 | increase the number. (See linkgit:git-reflog[1].) |
1098 | ||
1099 | * Relative to the tip of 'topic': knowing that your 'topic' has three | |
1100 | commits, the old tip of 'subsystem' must be `topic~3`. | |
1101 | ||
1102 | You can then transplant the old `subsystem..topic` to the new tip by | |
1103 | saying (for the reflog case, and assuming you are on 'topic' already): | |
1104 | ------------ | |
1105 | $ git rebase --onto subsystem subsystem@{1} | |
1106 | ------------ | |
1107 | ||
1108 | The ripple effect of a "hard case" recovery is especially bad: | |
1109 | 'everyone' downstream from 'topic' will now have to perform a "hard | |
1110 | case" recovery too! | |
1111 | ||
25cff9f1 | 1112 | REBASING MERGES |
81d395cc | 1113 | --------------- |
25cff9f1 JS |
1114 | |
1115 | The interactive rebase command was originally designed to handle | |
1116 | individual patch series. As such, it makes sense to exclude merge | |
1117 | commits from the todo list, as the developer may have merged the | |
1118 | then-current `master` while working on the branch, only to rebase | |
1119 | all the commits onto `master` eventually (skipping the merge | |
1120 | commits). | |
1121 | ||
1122 | However, there are legitimate reasons why a developer may want to | |
1123 | recreate merge commits: to keep the branch structure (or "commit | |
1124 | topology") when working on multiple, inter-related branches. | |
1125 | ||
1126 | In the following example, the developer works on a topic branch that | |
1127 | refactors the way buttons are defined, and on another topic branch | |
1128 | that uses that refactoring to implement a "Report a bug" button. The | |
1129 | output of `git log --graph --format=%s -5` may look like this: | |
1130 | ||
1131 | ------------ | |
1132 | * Merge branch 'report-a-bug' | |
1133 | |\ | |
1134 | | * Add the feedback button | |
1135 | * | Merge branch 'refactor-button' | |
1136 | |\ \ | |
1137 | | |/ | |
1138 | | * Use the Button class for all buttons | |
1139 | | * Extract a generic Button class from the DownloadButton one | |
1140 | ------------ | |
1141 | ||
1142 | The developer might want to rebase those commits to a newer `master` | |
1143 | while keeping the branch topology, for example when the first topic | |
1144 | branch is expected to be integrated into `master` much earlier than the | |
1145 | second one, say, to resolve merge conflicts with changes to the | |
1146 | DownloadButton class that made it into `master`. | |
1147 | ||
1148 | This rebase can be performed using the `--rebase-merges` option. | |
1149 | It will generate a todo list looking like this: | |
1150 | ||
1151 | ------------ | |
1152 | label onto | |
1153 | ||
1154 | # Branch: refactor-button | |
1155 | reset onto | |
1156 | pick 123456 Extract a generic Button class from the DownloadButton one | |
1157 | pick 654321 Use the Button class for all buttons | |
1158 | label refactor-button | |
1159 | ||
1160 | # Branch: report-a-bug | |
1161 | reset refactor-button # Use the Button class for all buttons | |
1162 | pick abcdef Add the feedback button | |
1163 | label report-a-bug | |
1164 | ||
1165 | reset onto | |
1166 | merge -C a1b2c3 refactor-button # Merge 'refactor-button' | |
1167 | merge -C 6f5e4d report-a-bug # Merge 'report-a-bug' | |
1168 | ------------ | |
1169 | ||
1170 | In contrast to a regular interactive rebase, there are `label`, `reset` | |
1171 | and `merge` commands in addition to `pick` ones. | |
1172 | ||
1173 | The `label` command associates a label with the current HEAD when that | |
1174 | command is executed. These labels are created as worktree-local refs | |
1175 | (`refs/rewritten/<label>`) that will be deleted when the rebase | |
1176 | finishes. That way, rebase operations in multiple worktrees linked to | |
1177 | the same repository do not interfere with one another. If the `label` | |
1178 | command fails, it is rescheduled immediately, with a helpful message how | |
1179 | to proceed. | |
1180 | ||
1181 | The `reset` command resets the HEAD, index and worktree to the specified | |
ad0b8f95 | 1182 | revision. It is similar to an `exec git reset --hard <label>`, but |
25cff9f1 JS |
1183 | refuses to overwrite untracked files. If the `reset` command fails, it is |
1184 | rescheduled immediately, with a helpful message how to edit the todo list | |
1185 | (this typically happens when a `reset` command was inserted into the todo | |
1186 | list manually and contains a typo). | |
1187 | ||
caafecfc JS |
1188 | The `merge` command will merge the specified revision(s) into whatever |
1189 | is HEAD at that time. With `-C <original-commit>`, the commit message of | |
25cff9f1 JS |
1190 | the specified merge commit will be used. When the `-C` is changed to |
1191 | a lower-case `-c`, the message will be opened in an editor after a | |
1192 | successful merge so that the user can edit the message. | |
1193 | ||
1194 | If a `merge` command fails for any reason other than merge conflicts (i.e. | |
1195 | when the merge operation did not even start), it is rescheduled immediately. | |
1196 | ||
f5a3c5e6 EN |
1197 | By default, the `merge` command will use the `ort` merge strategy for |
1198 | regular merges, and `octopus` for octopus merges. One can specify a | |
1199 | default strategy for all merges using the `--strategy` argument when | |
1200 | invoking rebase, or can override specific merges in the interactive | |
1201 | list of commands by using an `exec` command to call `git merge` | |
1202 | explicitly with a `--strategy` argument. Note that when calling `git | |
1203 | merge` explicitly like this, you can make use of the fact that the | |
1204 | labels are worktree-local refs (the ref `refs/rewritten/onto` would | |
1205 | correspond to the label `onto`, for example) in order to refer to the | |
1206 | branches you want to merge. | |
25cff9f1 JS |
1207 | |
1208 | Note: the first command (`label onto`) labels the revision onto which | |
1209 | the commits are rebased; The name `onto` is just a convention, as a nod | |
1210 | to the `--onto` option. | |
1211 | ||
1212 | It is also possible to introduce completely new merge commits from scratch | |
1213 | by adding a command of the form `merge <merge-head>`. This form will | |
1214 | generate a tentative commit message and always open an editor to let the | |
1215 | user edit it. This can be useful e.g. when a topic branch turns out to | |
1216 | address more than a single concern and wants to be split into two or | |
1217 | even more topic branches. Consider this todo list: | |
1218 | ||
1219 | ------------ | |
1220 | pick 192837 Switch from GNU Makefiles to CMake | |
1221 | pick 5a6c7e Document the switch to CMake | |
1222 | pick 918273 Fix detection of OpenSSL in CMake | |
1223 | pick afbecd http: add support for TLS v1.3 | |
1224 | pick fdbaec Fix detection of cURL in CMake on Windows | |
1225 | ------------ | |
1226 | ||
1227 | The one commit in this list that is not related to CMake may very well | |
1228 | have been motivated by working on fixing all those bugs introduced by | |
1229 | switching to CMake, but it addresses a different concern. To split this | |
1230 | branch into two topic branches, the todo list could be edited like this: | |
1231 | ||
1232 | ------------ | |
1233 | label onto | |
1234 | ||
1235 | pick afbecd http: add support for TLS v1.3 | |
1236 | label tlsv1.3 | |
1237 | ||
1238 | reset onto | |
1239 | pick 192837 Switch from GNU Makefiles to CMake | |
1240 | pick 918273 Fix detection of OpenSSL in CMake | |
1241 | pick fdbaec Fix detection of cURL in CMake on Windows | |
1242 | pick 5a6c7e Document the switch to CMake | |
1243 | label cmake | |
1244 | ||
1245 | reset onto | |
1246 | merge tlsv1.3 | |
1247 | merge cmake | |
1248 | ------------ | |
1249 | ||
414abf15 ÆAB |
1250 | CONFIGURATION |
1251 | ------------- | |
1252 | ||
1253 | include::config/rebase.txt[] | |
1254 | include::config/sequencer.txt[] | |
1255 | ||
7fc9d69f JH |
1256 | GIT |
1257 | --- | |
9e1f0a85 | 1258 | Part of the linkgit:git[1] suite |