]>
Commit | Line | Data |
---|---|---|
215a7ad1 JH |
1 | git-rebase(1) |
2 | ============= | |
7fc9d69f JH |
3 | |
4 | NAME | |
5 | ---- | |
c3f0baac | 6 | git-rebase - Forward-port local commits to the updated upstream head |
7fc9d69f JH |
7 | |
8 | SYNOPSIS | |
9 | -------- | |
e448ff87 | 10 | [verse] |
c2145384 | 11 | 'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] |
15a147e6 | 12 | [<upstream>] [<branch>] |
c2145384 | 13 | 'git rebase' [-i | --interactive] [options] [--exec <cmd>] --onto <newbase> |
be496621 | 14 | --root [<branch>] |
b1889c36 | 15 | 'git rebase' --continue | --skip | --abort |
031321c6 | 16 | |
7fc9d69f JH |
17 | DESCRIPTION |
18 | ----------- | |
0b444cdb | 19 | If <branch> is specified, 'git rebase' will perform an automatic |
5ca2db53 SP |
20 | `git checkout <branch>` before doing anything else. Otherwise |
21 | it remains on the current branch. | |
22 | ||
15a147e6 MZ |
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. If you are currently not on any | |
26 | branch or if the current branch does not have a configured upstream, | |
27 | the rebase will abort. | |
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 | |
be496621 TR |
31 | of commits that would be shown by `git log <upstream>..HEAD` (or |
32 | `git log HEAD`, if --root is specified). | |
5ca2db53 SP |
33 | |
34 | The current branch is reset to <upstream>, or <newbase> if the | |
35 | --onto option was supplied. This has the exact same effect as | |
9869099b BG |
36 | `git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set |
37 | to point at the tip of the branch before the reset. | |
5ca2db53 SP |
38 | |
39 | The commits that were previously saved into the temporary area are | |
ff905462 JK |
40 | then reapplied to the current branch, one by one, in order. Note that |
41 | any commits in HEAD which introduce the same textual changes as a commit | |
42 | in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream | |
43 | with a different commit message or timestamp will be skipped). | |
69a60af5 | 44 | |
031321c6 SE |
45 | It is possible that a merge failure will prevent this process from being |
46 | completely automatic. You will have to resolve any such merge failure | |
cc120056 | 47 | and run `git rebase --continue`. Another option is to bypass the commit |
5960bc9d | 48 | that caused the merge failure with `git rebase --skip`. To check out the |
51ef1daa JS |
49 | original <branch> and remove the .git/rebase-apply working files, use the |
50 | command `git rebase --abort` instead. | |
031321c6 | 51 | |
69a60af5 CW |
52 | Assume the following history exists and the current branch is "topic": |
53 | ||
031321c6 | 54 | ------------ |
69a60af5 CW |
55 | A---B---C topic |
56 | / | |
57 | D---E---F---G master | |
031321c6 | 58 | ------------ |
69a60af5 | 59 | |
228382ae | 60 | From this point, the result of either of the following commands: |
69a60af5 | 61 | |
031321c6 | 62 | |
b1889c36 JN |
63 | git rebase master |
64 | git rebase master topic | |
69a60af5 CW |
65 | |
66 | would be: | |
67 | ||
031321c6 | 68 | ------------ |
69a60af5 CW |
69 | A'--B'--C' topic |
70 | / | |
71 | D---E---F---G master | |
031321c6 | 72 | ------------ |
69a60af5 | 73 | |
ee55703b DN |
74 | *NOTE:* The latter form is just a short-hand of `git checkout topic` |
75 | followed by `git rebase master`. When rebase exits `topic` will | |
76 | remain the checked-out branch. | |
69a60af5 | 77 | |
ff905462 JK |
78 | If the upstream branch already contains a change you have made (e.g., |
79 | because you mailed a patch which was applied upstream), then that commit | |
b1889c36 | 80 | will be skipped. For example, running `git rebase master` on the |
ff905462 JK |
81 | following history (in which A' and A introduce the same set of changes, |
82 | but have different committer information): | |
83 | ||
84 | ------------ | |
85 | A---B---C topic | |
86 | / | |
87 | D---E---A'---F master | |
88 | ------------ | |
89 | ||
90 | will result in: | |
91 | ||
92 | ------------ | |
93 | B'---C' topic | |
94 | / | |
95 | D---E---A'---F master | |
96 | ------------ | |
97 | ||
e52775f4 JN |
98 | Here is how you would transplant a topic branch based on one |
99 | branch to another, to pretend that you forked the topic branch | |
100 | from the latter branch, using `rebase --onto`. | |
69a60af5 | 101 | |
e52775f4 | 102 | First let's assume your 'topic' is based on branch 'next'. |
e2b850b2 | 103 | For example, a feature developed in 'topic' depends on some |
e52775f4 | 104 | functionality which is found in 'next'. |
69a60af5 | 105 | |
031321c6 | 106 | ------------ |
e52775f4 JN |
107 | o---o---o---o---o master |
108 | \ | |
109 | o---o---o---o---o next | |
110 | \ | |
111 | o---o---o topic | |
112 | ------------ | |
113 | ||
e2b850b2 GD |
114 | We want to make 'topic' forked from branch 'master'; for example, |
115 | because the functionality on which 'topic' depends was merged into the | |
116 | more stable 'master' branch. We want our tree to look like this: | |
e52775f4 JN |
117 | |
118 | ------------ | |
119 | o---o---o---o---o master | |
120 | | \ | |
121 | | o'--o'--o' topic | |
122 | \ | |
123 | o---o---o---o---o next | |
031321c6 | 124 | ------------ |
7fc9d69f | 125 | |
e52775f4 JN |
126 | We can get this using the following command: |
127 | ||
b1889c36 | 128 | git rebase --onto master next topic |
e52775f4 JN |
129 | |
130 | ||
131 | Another example of --onto option is to rebase part of a | |
132 | branch. If we have the following situation: | |
133 | ||
134 | ------------ | |
135 | H---I---J topicB | |
136 | / | |
137 | E---F---G topicA | |
138 | / | |
139 | A---B---C---D master | |
140 | ------------ | |
141 | ||
142 | then the command | |
143 | ||
b1889c36 | 144 | git rebase --onto master topicA topicB |
e52775f4 JN |
145 | |
146 | would result in: | |
147 | ||
148 | ------------ | |
149 | H'--I'--J' topicB | |
150 | / | |
151 | | E---F---G topicA | |
152 | |/ | |
153 | A---B---C---D master | |
154 | ------------ | |
155 | ||
156 | This is useful when topicB does not depend on topicA. | |
157 | ||
ea81fcc5 SP |
158 | A range of commits could also be removed with rebase. If we have |
159 | the following situation: | |
160 | ||
161 | ------------ | |
162 | E---F---G---H---I---J topicA | |
163 | ------------ | |
164 | ||
165 | then the command | |
166 | ||
b1889c36 | 167 | git rebase --onto topicA~5 topicA~3 topicA |
ea81fcc5 SP |
168 | |
169 | would result in the removal of commits F and G: | |
170 | ||
171 | ------------ | |
172 | E---H'---I'---J' topicA | |
173 | ------------ | |
174 | ||
175 | This is useful if F and G were flawed in some way, or should not be | |
176 | part of topicA. Note that the argument to --onto and the <upstream> | |
177 | parameter can be any valid commit-ish. | |
178 | ||
0b444cdb TR |
179 | In case of conflict, 'git rebase' will stop at the first problematic commit |
180 | and leave conflict markers in the tree. You can use 'git diff' to locate | |
031321c6 SE |
181 | the markers (<<<<<<) and make edits to resolve the conflict. For each |
182 | file you edit, you need to tell git that the conflict has been resolved, | |
183 | typically this would be done with | |
184 | ||
185 | ||
d7f078b8 | 186 | git add <filename> |
031321c6 SE |
187 | |
188 | ||
189 | After resolving the conflict manually and updating the index with the | |
190 | desired resolution, you can continue the rebasing process with | |
191 | ||
192 | ||
193 | git rebase --continue | |
8978d043 | 194 | |
8978d043 | 195 | |
0b444cdb | 196 | Alternatively, you can undo the 'git rebase' with |
8978d043 | 197 | |
031321c6 SE |
198 | |
199 | git rebase --abort | |
8978d043 | 200 | |
a9c3821c TAV |
201 | CONFIGURATION |
202 | ------------- | |
203 | ||
204 | rebase.stat:: | |
205 | Whether to show a diffstat of what changed upstream since the last | |
206 | rebase. False by default. | |
207 | ||
dd1e5b31 HV |
208 | rebase.autosquash:: |
209 | If set to true enable '--autosquash' option by default. | |
210 | ||
7fc9d69f JH |
211 | OPTIONS |
212 | ------- | |
c2145384 | 213 | --onto <newbase>:: |
69a60af5 CW |
214 | Starting point at which to create the new commits. If the |
215 | --onto option is not specified, the starting point is | |
ea81fcc5 SP |
216 | <upstream>. May be any valid commit, and not just an |
217 | existing branch name. | |
873c3472 | 218 | + |
b9190e79 | 219 | As a special case, you may use "A\...B" as a shortcut for the |
873c3472 MG |
220 | merge base of A and B if there is exactly one merge base. You can |
221 | leave out at most one of A and B, in which case it defaults to HEAD. | |
69a60af5 | 222 | |
52a22d1e | 223 | <upstream>:: |
ea81fcc5 | 224 | Upstream branch to compare against. May be any valid commit, |
15a147e6 MZ |
225 | not just an existing branch name. Defaults to the configured |
226 | upstream for the current branch. | |
7fc9d69f | 227 | |
228382ae | 228 | <branch>:: |
52a22d1e | 229 | Working branch; defaults to HEAD. |
7fc9d69f | 230 | |
031321c6 SE |
231 | --continue:: |
232 | Restart the rebasing process after having resolved a merge conflict. | |
233 | ||
234 | --abort:: | |
5960bc9d MZ |
235 | Abort the rebase operation and reset HEAD to the original |
236 | branch. If <branch> was provided when the rebase operation was | |
237 | started, then HEAD will be reset to <branch>. Otherwise HEAD | |
238 | will be reset to where it was when the rebase operation was | |
239 | started. | |
031321c6 | 240 | |
90e1818f NH |
241 | --keep-empty:: |
242 | Keep the commits that do not change anything from its | |
243 | parents in the result. | |
244 | ||
58634dbf EW |
245 | --skip:: |
246 | Restart the rebasing process by skipping the current patch. | |
58634dbf | 247 | |
3240240f SB |
248 | -m:: |
249 | --merge:: | |
58634dbf EW |
250 | Use merging strategies to rebase. When the recursive (default) merge |
251 | strategy is used, this allows rebase to be aware of renames on the | |
252 | upstream side. | |
31ddd1ee TR |
253 | + |
254 | Note that a rebase merge works by replaying each commit from the working | |
255 | branch on top of the <upstream> branch. Because of this, when a merge | |
256 | conflict happens, the side reported as 'ours' is the so-far rebased | |
257 | series, starting with <upstream>, and 'theirs' is the working branch. In | |
258 | other words, the sides are swapped. | |
58634dbf | 259 | |
3240240f SB |
260 | -s <strategy>:: |
261 | --strategy=<strategy>:: | |
06f39190 | 262 | Use the given merge strategy. |
0b444cdb | 263 | If there is no `-s` option 'git merge-recursive' is used |
31ddd1ee TR |
264 | instead. This implies --merge. |
265 | + | |
0b444cdb | 266 | Because 'git rebase' replays each commit from the working branch |
31ddd1ee TR |
267 | on top of the <upstream> branch using the given strategy, using |
268 | the 'ours' strategy simply discards all patches from the <branch>, | |
269 | which makes little sense. | |
58634dbf | 270 | |
93ce190c ML |
271 | -X <strategy-option>:: |
272 | --strategy-option=<strategy-option>:: | |
273 | Pass the <strategy-option> through to the merge strategy. | |
6cf378f0 | 274 | This implies `--merge` and, if no strategy has been |
93ce190c ML |
275 | specified, `-s recursive`. Note the reversal of 'ours' and |
276 | 'theirs' as noted in above for the `-m` option. | |
277 | ||
0e987a12 SB |
278 | -q:: |
279 | --quiet:: | |
280 | Be quiet. Implies --no-stat. | |
281 | ||
3240240f SB |
282 | -v:: |
283 | --verbose:: | |
a9c3821c TAV |
284 | Be verbose. Implies --stat. |
285 | ||
286 | --stat:: | |
287 | Show a diffstat of what changed upstream since the last rebase. The | |
288 | diffstat is also controlled by the configuration option rebase.stat. | |
289 | ||
290 | -n:: | |
291 | --no-stat:: | |
292 | Do not show a diffstat as part of the rebase process. | |
b758789c | 293 | |
fd631d58 NS |
294 | --no-verify:: |
295 | This option bypasses the pre-rebase hook. See also linkgit:githooks[5]. | |
296 | ||
7baf9c4b MZ |
297 | --verify:: |
298 | Allows the pre-rebase hook to run, which is the default. This option can | |
299 | be used to override --no-verify. See also linkgit:githooks[5]. | |
300 | ||
67dad687 MT |
301 | -C<n>:: |
302 | Ensure at least <n> lines of surrounding context match before | |
303 | and after each change. When fewer lines of surrounding | |
304 | context exist they all must match. By default no context is | |
305 | ever ignored. | |
306 | ||
5e75d56f MB |
307 | -f:: |
308 | --force-rebase:: | |
309 | Force the rebase even if the current branch is a descendant | |
b4995494 | 310 | of the commit you are rebasing onto. Normally non-interactive rebase will |
5e75d56f MB |
311 | exit with the message "Current branch is up to date" in such a |
312 | situation. | |
b4995494 MB |
313 | Incompatible with the --interactive option. |
314 | + | |
315 | You may find this (or --no-ff with an interactive rebase) helpful after | |
316 | reverting a topic branch merge, as this option recreates the topic branch with | |
317 | fresh commits so it can be remerged successfully without needing to "revert | |
318 | the reversion" (see the | |
319 | link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). | |
5e75d56f | 320 | |
86c91f91 | 321 | --ignore-whitespace:: |
749485f6 | 322 | --whitespace=<option>:: |
0b444cdb | 323 | These flag are passed to the 'git apply' program |
5162e697 | 324 | (see linkgit:git-apply[1]) that applies the patch. |
7fe54385 | 325 | Incompatible with the --interactive option. |
059f446d | 326 | |
570ccad3 MB |
327 | --committer-date-is-author-date:: |
328 | --ignore-date:: | |
0b444cdb | 329 | These flags are passed to 'git am' to easily change the dates |
570ccad3 | 330 | of the rebased commits (see linkgit:git-am[1]). |
56a05720 | 331 | Incompatible with the --interactive option. |
570ccad3 | 332 | |
3240240f SB |
333 | -i:: |
334 | --interactive:: | |
1b1dce4b | 335 | Make a list of the commits which are about to be rebased. Let the |
f0fd889d JS |
336 | user edit that list before rebasing. This mode can also be used to |
337 | split commits (see SPLITTING COMMITS below). | |
1b1dce4b | 338 | |
3240240f SB |
339 | -p:: |
340 | --preserve-merges:: | |
f8cca019 | 341 | Instead of ignoring merges, try to recreate them. |
cddb42d2 JN |
342 | + |
343 | This uses the `--interactive` machinery internally, but combining it | |
344 | with the `--interactive` option explicitly is generally not a good | |
345 | idea unless you know what you are doing (see BUGS below). | |
346 | ||
c2145384 LK |
347 | -x <cmd>:: |
348 | --exec <cmd>:: | |
349 | Append "exec <cmd>" after each line creating a commit in the | |
350 | final history. <cmd> will be interpreted as one or more shell | |
351 | commands. | |
352 | + | |
353 | This option can only be used with the `--interactive` option | |
354 | (see INTERACTIVE MODE below). | |
355 | + | |
356 | You may execute several commands by either using one instance of `--exec` | |
357 | with several commands: | |
358 | + | |
359 | git rebase -i --exec "cmd1 && cmd2 && ..." | |
360 | + | |
361 | or by giving more than one `--exec`: | |
362 | + | |
363 | git rebase -i --exec "cmd1" --exec "cmd2" --exec ... | |
364 | + | |
365 | If `--autosquash` is used, "exec" lines will not be appended for | |
366 | the intermediate commits, and will only appear at the end of each | |
367 | squash/fixup series. | |
f09c9b8c | 368 | |
be496621 TR |
369 | --root:: |
370 | Rebase all commits reachable from <branch>, instead of | |
371 | limiting them with an <upstream>. This allows you to rebase | |
372 | the root commit(s) on a branch. Must be used with --onto, and | |
373 | will skip changes already contained in <newbase> (instead of | |
374 | <upstream>). When used together with --preserve-merges, 'all' | |
375 | root commits will be rewritten to have <newbase> as parent | |
376 | instead. | |
377 | ||
f59baa50 | 378 | --autosquash:: |
dd1e5b31 | 379 | --no-autosquash:: |
f59baa50 NS |
380 | When the commit log message begins with "squash! ..." (or |
381 | "fixup! ..."), and there is a commit whose title begins with | |
382 | the same ..., automatically modify the todo list of rebase -i | |
42cfcd20 | 383 | so that the commit marked for squashing comes right after the |
f59baa50 NS |
384 | commit to be modified, and change the action of the moved |
385 | commit from `pick` to `squash` (or `fixup`). | |
386 | + | |
b4995494 | 387 | This option is only valid when the '--interactive' option is used. |
dd1e5b31 HV |
388 | + |
389 | If the '--autosquash' option is enabled by default using the | |
390 | configuration variable `rebase.autosquash`, this option can be | |
391 | used to override and disable this setting. | |
b4995494 MB |
392 | |
393 | --no-ff:: | |
394 | With --interactive, cherry-pick all rebased commits instead of | |
395 | fast-forwarding over the unchanged ones. This ensures that the | |
396 | entire history of the rebased branch is composed of new commits. | |
397 | + | |
398 | Without --interactive, this is a synonym for --force-rebase. | |
399 | + | |
400 | You may find this helpful after reverting a topic branch merge, as this option | |
401 | recreates the topic branch with fresh commits so it can be remerged | |
402 | successfully without needing to "revert the reversion" (see the | |
403 | link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details). | |
f59baa50 | 404 | |
58634dbf EW |
405 | include::merge-strategies.txt[] |
406 | ||
031321c6 SE |
407 | NOTES |
408 | ----- | |
90d1c08e | 409 | |
0b444cdb | 410 | You should understand the implications of using 'git rebase' on a |
90d1c08e TR |
411 | repository that you share. See also RECOVERING FROM UPSTREAM REBASE |
412 | below. | |
031321c6 | 413 | |
467c0197 | 414 | When the git-rebase command is run, it will first execute a "pre-rebase" |
031321c6 SE |
415 | hook if one exists. You can use this hook to do sanity checks and |
416 | reject the rebase if it isn't appropriate. Please see the template | |
417 | pre-rebase hook script for an example. | |
418 | ||
702088af | 419 | Upon completion, <branch> will be the current branch. |
031321c6 | 420 | |
1b1dce4b JS |
421 | INTERACTIVE MODE |
422 | ---------------- | |
423 | ||
424 | Rebasing interactively means that you have a chance to edit the commits | |
425 | which are rebased. You can reorder the commits, and you can | |
426 | remove them (weeding out bad or otherwise unwanted patches). | |
427 | ||
428 | The interactive mode is meant for this type of workflow: | |
429 | ||
430 | 1. have a wonderful idea | |
431 | 2. hack on the code | |
432 | 3. prepare a series for submission | |
433 | 4. submit | |
434 | ||
435 | where point 2. consists of several instances of | |
436 | ||
d3f2475c NBL |
437 | a) regular use |
438 | ||
1b1dce4b JS |
439 | 1. finish something worthy of a commit |
440 | 2. commit | |
d3f2475c NBL |
441 | |
442 | b) independent fixup | |
443 | ||
1b1dce4b JS |
444 | 1. realize that something does not work |
445 | 2. fix that | |
446 | 3. commit it | |
447 | ||
448 | Sometimes the thing fixed in b.2. cannot be amended to the not-quite | |
449 | perfect commit it fixes, because that commit is buried deeply in a | |
450 | patch series. That is exactly what interactive rebase is for: use it | |
451 | after plenty of "a"s and "b"s, by rearranging and editing | |
452 | commits, and squashing multiple commits into one. | |
453 | ||
454 | Start it with the last commit you want to retain as-is: | |
455 | ||
456 | git rebase -i <after-this-commit> | |
457 | ||
458 | An editor will be fired up with all the commits in your current branch | |
459 | (ignoring merge commits), which come after the given commit. You can | |
460 | reorder the commits in this list to your heart's content, and you can | |
461 | remove them. The list looks more or less like this: | |
462 | ||
463 | ------------------------------------------- | |
464 | pick deadbee The oneline of this commit | |
465 | pick fa1afe1 The oneline of the next commit | |
466 | ... | |
467 | ------------------------------------------- | |
468 | ||
0b444cdb | 469 | The oneline descriptions are purely for your pleasure; 'git rebase' will |
1b1dce4b JS |
470 | not look at them but at the commit names ("deadbee" and "fa1afe1" in this |
471 | example), so do not delete or edit the names. | |
472 | ||
473 | By replacing the command "pick" with the command "edit", you can tell | |
0b444cdb | 474 | 'git rebase' to stop after applying that commit, so that you can edit |
1b1dce4b JS |
475 | the files and/or the commit message, amend the commit, and continue |
476 | rebasing. | |
477 | ||
6741aa6c BG |
478 | If you just want to edit the commit message for a commit, replace the |
479 | command "pick" with the command "reword". | |
480 | ||
1b1dce4b | 481 | If you want to fold two or more commits into one, replace the command |
0205e72f MH |
482 | "pick" for the second and subsequent commits with "squash" or "fixup". |
483 | If the commits had different authors, the folded commit will be | |
484 | attributed to the author of the first commit. The suggested commit | |
485 | message for the folded commit is the concatenation of the commit | |
486 | messages of the first commit and of those with the "squash" command, | |
487 | but omits the commit messages of commits with the "fixup" command. | |
1b1dce4b | 488 | |
0b444cdb | 489 | 'git rebase' will stop when "pick" has been replaced with "edit" or |
6741aa6c BG |
490 | when a command fails due to merge errors. When you are done editing |
491 | and/or resolving conflicts you can continue with `git rebase --continue`. | |
1b1dce4b JS |
492 | |
493 | For example, if you want to reorder the last 5 commits, such that what | |
494 | was HEAD~4 becomes the new HEAD. To achieve that, you would call | |
0b444cdb | 495 | 'git rebase' like this: |
1b1dce4b JS |
496 | |
497 | ---------------------- | |
498 | $ git rebase -i HEAD~5 | |
499 | ---------------------- | |
500 | ||
501 | And move the first patch to the end of the list. | |
502 | ||
f09c9b8c JS |
503 | You might want to preserve merges, if you have a history like this: |
504 | ||
505 | ------------------ | |
506 | X | |
507 | \ | |
508 | A---M---B | |
509 | / | |
510 | ---o---O---P---Q | |
511 | ------------------ | |
512 | ||
513 | Suppose you want to rebase the side branch starting at "A" to "Q". Make | |
514 | sure that the current HEAD is "B", and call | |
515 | ||
516 | ----------------------------- | |
517 | $ git rebase -i -p --onto Q O | |
518 | ----------------------------- | |
519 | ||
cd035b1c MM |
520 | Reordering and editing commits usually creates untested intermediate |
521 | steps. You may want to check that your history editing did not break | |
522 | anything by running a test, or at least recompiling at intermediate | |
523 | points in history by using the "exec" command (shortcut "x"). You may | |
524 | do so by creating a todo list like this one: | |
525 | ||
526 | ------------------------------------------- | |
527 | pick deadbee Implement feature XXX | |
528 | fixup f1a5c00 Fix to feature XXX | |
529 | exec make | |
530 | pick c0ffeee The oneline of the next commit | |
531 | edit deadbab The oneline of the commit after | |
532 | exec cd subdir; make test | |
533 | ... | |
534 | ------------------------------------------- | |
535 | ||
536 | The interactive rebase will stop when a command fails (i.e. exits with | |
537 | non-0 status) to give you an opportunity to fix the problem. You can | |
538 | continue with `git rebase --continue`. | |
539 | ||
540 | The "exec" command launches the command in a shell (the one specified | |
541 | in `$SHELL`, or the default shell if `$SHELL` is not set), so you can | |
542 | use shell features (like "cd", ">", ";" ...). The command is run from | |
543 | the root of the working tree. | |
f0fd889d | 544 | |
c2145384 LK |
545 | ---------------------------------- |
546 | $ git rebase -i --exec "make test" | |
547 | ---------------------------------- | |
548 | ||
549 | This command lets you check that intermediate commits are compilable. | |
550 | The todo list becomes like that: | |
551 | ||
552 | -------------------- | |
553 | pick 5928aea one | |
554 | exec make test | |
555 | pick 04d0fda two | |
556 | exec make test | |
557 | pick ba46169 three | |
558 | exec make test | |
559 | pick f4593f9 four | |
560 | exec make test | |
561 | -------------------- | |
562 | ||
f0fd889d JS |
563 | SPLITTING COMMITS |
564 | ----------------- | |
565 | ||
566 | In interactive mode, you can mark commits with the action "edit". However, | |
0b444cdb | 567 | this does not necessarily mean that 'git rebase' expects the result of this |
f0fd889d JS |
568 | edit to be exactly one commit. Indeed, you can undo the commit, or you can |
569 | add other commits. This can be used to split a commit into two: | |
570 | ||
483bc4f0 | 571 | - Start an interactive rebase with `git rebase -i <commit>^`, where |
f0fd889d JS |
572 | <commit> is the commit you want to split. In fact, any commit range |
573 | will do, as long as it contains that commit. | |
574 | ||
575 | - Mark the commit you want to split with the action "edit". | |
576 | ||
483bc4f0 | 577 | - When it comes to editing that commit, execute `git reset HEAD^`. The |
f0fd889d JS |
578 | effect is that the HEAD is rewound by one, and the index follows suit. |
579 | However, the working tree stays the same. | |
580 | ||
581 | - Now add the changes to the index that you want to have in the first | |
483bc4f0 | 582 | commit. You can use `git add` (possibly interactively) or |
0b444cdb | 583 | 'git gui' (or both) to do that. |
f0fd889d JS |
584 | |
585 | - Commit the now-current index with whatever commit message is appropriate | |
586 | now. | |
587 | ||
588 | - Repeat the last two steps until your working tree is clean. | |
589 | ||
483bc4f0 | 590 | - Continue the rebase with `git rebase --continue`. |
f0fd889d JS |
591 | |
592 | If you are not absolutely sure that the intermediate revisions are | |
593 | consistent (they compile, pass the testsuite, etc.) you should use | |
0b444cdb | 594 | 'git stash' to stash away the not-yet-committed changes |
f0fd889d JS |
595 | after each commit, test, and amend the commit if fixes are necessary. |
596 | ||
597 | ||
90d1c08e TR |
598 | RECOVERING FROM UPSTREAM REBASE |
599 | ------------------------------- | |
600 | ||
601 | Rebasing (or any other form of rewriting) a branch that others have | |
602 | based work on is a bad idea: anyone downstream of it is forced to | |
603 | manually fix their history. This section explains how to do the fix | |
604 | from the downstream's point of view. The real fix, however, would be | |
605 | to avoid rebasing the upstream in the first place. | |
606 | ||
607 | To illustrate, suppose you are in a situation where someone develops a | |
608 | 'subsystem' branch, and you are working on a 'topic' that is dependent | |
609 | on this 'subsystem'. You might end up with a history like the | |
610 | following: | |
611 | ||
612 | ------------ | |
613 | o---o---o---o---o---o---o---o---o master | |
614 | \ | |
615 | o---o---o---o---o subsystem | |
616 | \ | |
617 | *---*---* topic | |
618 | ------------ | |
619 | ||
620 | If 'subsystem' is rebased against 'master', the following happens: | |
621 | ||
622 | ------------ | |
623 | o---o---o---o---o---o---o---o master | |
624 | \ \ | |
625 | o---o---o---o---o o'--o'--o'--o'--o' subsystem | |
626 | \ | |
627 | *---*---* topic | |
628 | ------------ | |
629 | ||
630 | If you now continue development as usual, and eventually merge 'topic' | |
631 | to 'subsystem', the commits from 'subsystem' will remain duplicated forever: | |
632 | ||
633 | ------------ | |
634 | o---o---o---o---o---o---o---o master | |
635 | \ \ | |
636 | o---o---o---o---o o'--o'--o'--o'--o'--M subsystem | |
637 | \ / | |
638 | *---*---*-..........-*--* topic | |
639 | ------------ | |
640 | ||
641 | Such duplicates are generally frowned upon because they clutter up | |
642 | history, making it harder to follow. To clean things up, you need to | |
643 | transplant the commits on 'topic' to the new 'subsystem' tip, i.e., | |
644 | rebase 'topic'. This becomes a ripple effect: anyone downstream from | |
645 | 'topic' is forced to rebase too, and so on! | |
646 | ||
647 | There are two kinds of fixes, discussed in the following subsections: | |
648 | ||
649 | Easy case: The changes are literally the same.:: | |
650 | ||
651 | This happens if the 'subsystem' rebase was a simple rebase and | |
652 | had no conflicts. | |
653 | ||
654 | Hard case: The changes are not the same.:: | |
655 | ||
656 | This happens if the 'subsystem' rebase had conflicts, or used | |
6cf378f0 JK |
657 | `--interactive` to omit, edit, squash, or fixup commits; or |
658 | if the upstream used one of `commit --amend`, `reset`, or | |
90d1c08e TR |
659 | `filter-branch`. |
660 | ||
661 | ||
662 | The easy case | |
663 | ~~~~~~~~~~~~~ | |
664 | ||
665 | Only works if the changes (patch IDs based on the diff contents) on | |
666 | 'subsystem' are literally the same before and after the rebase | |
667 | 'subsystem' did. | |
668 | ||
0b444cdb | 669 | In that case, the fix is easy because 'git rebase' knows to skip |
90d1c08e TR |
670 | changes that are already present in the new upstream. So if you say |
671 | (assuming you're on 'topic') | |
672 | ------------ | |
673 | $ git rebase subsystem | |
674 | ------------ | |
675 | you will end up with the fixed history | |
676 | ------------ | |
677 | o---o---o---o---o---o---o---o master | |
678 | \ | |
679 | o'--o'--o'--o'--o' subsystem | |
680 | \ | |
681 | *---*---* topic | |
682 | ------------ | |
683 | ||
684 | ||
685 | The hard case | |
686 | ~~~~~~~~~~~~~ | |
687 | ||
688 | Things get more complicated if the 'subsystem' changes do not exactly | |
689 | correspond to the ones before the rebase. | |
690 | ||
691 | NOTE: While an "easy case recovery" sometimes appears to be successful | |
692 | even in the hard case, it may have unintended consequences. For | |
693 | example, a commit that was removed via `git rebase | |
6cf378f0 | 694 | --interactive` will be **resurrected**! |
90d1c08e | 695 | |
0b444cdb | 696 | The idea is to manually tell 'git rebase' "where the old 'subsystem' |
90d1c08e TR |
697 | ended and your 'topic' began", that is, what the old merge-base |
698 | between them was. You will have to find a way to name the last commit | |
699 | of the old 'subsystem', for example: | |
700 | ||
0b444cdb | 701 | * With the 'subsystem' reflog: after 'git fetch', the old tip of |
6cf378f0 | 702 | 'subsystem' is at `subsystem@{1}`. Subsequent fetches will |
90d1c08e TR |
703 | increase the number. (See linkgit:git-reflog[1].) |
704 | ||
705 | * Relative to the tip of 'topic': knowing that your 'topic' has three | |
706 | commits, the old tip of 'subsystem' must be `topic~3`. | |
707 | ||
708 | You can then transplant the old `subsystem..topic` to the new tip by | |
709 | saying (for the reflog case, and assuming you are on 'topic' already): | |
710 | ------------ | |
711 | $ git rebase --onto subsystem subsystem@{1} | |
712 | ------------ | |
713 | ||
714 | The ripple effect of a "hard case" recovery is especially bad: | |
715 | 'everyone' downstream from 'topic' will now have to perform a "hard | |
716 | case" recovery too! | |
717 | ||
cddb42d2 JN |
718 | BUGS |
719 | ---- | |
720 | The todo list presented by `--preserve-merges --interactive` does not | |
721 | represent the topology of the revision graph. Editing commits and | |
722 | rewording their commit messages should work fine, but attempts to | |
723 | reorder commits tend to produce counterintuitive results. | |
724 | ||
725 | For example, an attempt to rearrange | |
726 | ------------ | |
727 | 1 --- 2 --- 3 --- 4 --- 5 | |
728 | ------------ | |
729 | to | |
730 | ------------ | |
731 | 1 --- 2 --- 4 --- 3 --- 5 | |
732 | ------------ | |
733 | by moving the "pick 4" line will result in the following history: | |
734 | ------------ | |
735 | 3 | |
736 | / | |
737 | 1 --- 2 --- 4 --- 5 | |
738 | ------------ | |
739 | ||
7fc9d69f JH |
740 | GIT |
741 | --- | |
9e1f0a85 | 742 | Part of the linkgit:git[1] suite |