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