SYNOPSIS
--------
[verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] [-C<n>]
- [-p | --preserve-merges] [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
+ [-s <strategy> | --strategy=<strategy>]
+ [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
+ [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
DESCRIPTION
`git reset --hard <upstream>` (or <newbase>).
The commits that were previously saved into the temporary area are
-then reapplied to the current branch, one by one, in order.
+then reapplied to the current branch, one by one, in order. Note that
+any commits in HEAD which introduce the same textual changes as a commit
+in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream
+with a different commit message or timestamp will be skipped).
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
The latter form is just a short-hand of `git checkout topic`
followed by `git rebase master`.
+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
+will be skipped. For example, running `git-rebase master` on the
+following history (in which A' and A introduce the same set of changes,
+but have different committer information):
+
+------------
+ A---B---C topic
+ /
+ D---E---A'---F master
+------------
+
+will result in:
+
+------------
+ B'---C' topic
+ /
+ D---E---A'---F master
+------------
+
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
--skip::
Restart the rebasing process by skipping the current patch.
--m, \--merge::
+-m::
+--merge::
Use merging strategies to rebase. When the recursive (default) merge
strategy is used, this allows rebase to be aware of renames on the
upstream side.
--s <strategy>, \--strategy=<strategy>::
+-s <strategy>::
+--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
If there is no `-s` option, a built-in list of strategies
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise). This implies --merge.
--v, \--verbose::
+-v::
+--verbose::
Display a diffstat of what changed upstream since the last rebase.
-C<n>::
context exist they all must match. By default no context is
ever ignored.
--i, \--interactive::
+--whitespace=<nowarn|warn|error|error-all|strip>::
+ This flag is passed to the `git-apply` program
+ (see linkgit:git-apply[1]) that applies the patch.
+
+-i::
+--interactive::
Make a list of the commits which are about to be rebased. Let the
user edit that list before rebasing. This mode can also be used to
split commits (see SPLITTING COMMITS below).
--p, \--preserve-merges::
+-p::
+--preserve-merges::
Instead of ignoring merges, try to recreate them. This option
only works in interactive mode.
reject the rebase if it isn't appropriate. Please see the template
pre-rebase hook script for an example.
-You must be in the top directory of your project to start (or continue)
-a rebase. Upon completion, <branch> will be the current branch.
+Upon completion, <branch> will be the current branch.
INTERACTIVE MODE
----------------
However, the working tree stays the same.
- Now add the changes to the index that you want to have in the first
- commit. You can use gitlink:git-add[1] (possibly interactively) and/or
- gitlink:git-gui[1] to do that.
+ commit. You can use linkgit:git-add[1] (possibly interactively) and/or
+ linkgit:git-gui[1] to do that.
- Commit the now-current index with whatever commit message is appropriate
now.
If you are not absolutely sure that the intermediate revisions are
consistent (they compile, pass the testsuite, etc.) you should use
-gitlink:git-stash[1] to stash away the not-yet-committed changes
+linkgit:git-stash[1] to stash away the not-yet-committed changes
after each commit, test, and amend the commit if fixes are necessary.
GIT
---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[1] suite