[<upstream>] [<branch>]
'git rebase' [-i | --interactive] [options] --onto <newbase>
--root [<branch>]
-
'git rebase' --continue | --skip | --abort
DESCRIPTION
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
and run `git rebase --continue`. Another option is to bypass the commit
-that caused the merge failure with `git rebase --skip`. To restore the
+that caused the merge failure with `git rebase --skip`. To check out the
original <branch> and remove the .git/rebase-apply working files, use the
command `git rebase --abort` instead.
D---E---F---G master
------------
-The latter form is just a short-hand of `git checkout topic`
-followed by `git rebase master`.
+*NOTE:* The latter form is just a short-hand of `git checkout topic`
+followed by `git rebase master`. When rebase exits `topic` will
+remain the checked-out branch.
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
Restart the rebasing process after having resolved a merge conflict.
--abort::
- Restore the original branch and abort the rebase operation.
+ Abort the rebase operation and reset HEAD to the original
+ branch. If <branch> was provided when the rebase operation was
+ started, then HEAD will be reset to <branch>. Otherwise HEAD
+ will be reset to where it was when the rebase operation was
+ started.
+
+--keep-empty::
+ Keep the commits that do not change anything from its
+ parents in the result.
--skip::
Restart the rebasing process by skipping the current patch.
-X <strategy-option>::
--strategy-option=<strategy-option>::
Pass the <strategy-option> through to the merge strategy.
- This implies `\--merge` and, if no strategy has been
+ This implies `--merge` and, if no strategy has been
specified, `-s recursive`. Note the reversal of 'ours' and
'theirs' as noted in above for the `-m` option.
where point 2. consists of several instances of
-a. regular use
+a) regular use
+
1. finish something worthy of a commit
2. commit
-b. independent fixup
+
+b) independent fixup
+
1. realize that something does not work
2. fix that
3. commit it
Hard case: The changes are not the same.::
This happens if the 'subsystem' rebase had conflicts, or used
- `\--interactive` to omit, edit, squash, or fixup commits; or
- if the upstream used one of `commit \--amend`, `reset`, or
+ `--interactive` to omit, edit, squash, or fixup commits; or
+ if the upstream used one of `commit --amend`, `reset`, or
`filter-branch`.
NOTE: While an "easy case recovery" sometimes appears to be successful
even in the hard case, it may have unintended consequences. For
example, a commit that was removed via `git rebase
- \--interactive` will be **resurrected**!
+ --interactive` will be **resurrected**!
The idea is to manually tell 'git rebase' "where the old 'subsystem'
ended and your 'topic' began", that is, what the old merge-base
of the old 'subsystem', for example:
* With the 'subsystem' reflog: after 'git fetch', the old tip of
- 'subsystem' is at `subsystem@\{1}`. Subsequent fetches will
+ 'subsystem' is at `subsystem@{1}`. Subsequent fetches will
increase the number. (See linkgit:git-reflog[1].)
* Relative to the tip of 'topic': knowing that your 'topic' has three
'everyone' downstream from 'topic' will now have to perform a "hard
case" recovery too!
-
BUGS
----
The todo list presented by `--preserve-merges --interactive` does not
1 --- 2 --- 4 --- 5
------------
-Authors
-------
-Written by Junio C Hamano <gitster@pobox.com> and
-Johannes E. Schindelin <johannes.schindelin@gmx.de>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
GIT
---
Part of the linkgit:git[1] suite