--onto option is not specified, the starting point is
<upstream>. May be any valid commit, and not just an
existing branch name.
++
+As a special case, you may use "A...B" as a shortcut for the
+merge base of A and B if there is exactly one merge base. You can
+leave out at most one of A and B, in which case it defaults to HEAD.
<upstream>::
Upstream branch to compare against. May be any valid commit,
the 'ours' strategy simply discards all patches from the <branch>,
which makes little sense.
+-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
+ specified, `-s recursive`. Note the reversal of 'ours' and
+ 'theirs' as noted in above for the `-m` option.
+
-q::
--quiet::
Be quiet. Implies --no-stat.
-f::
--force-rebase::
Force the rebase even if the current branch is a descendant
- of the commit you are rebasing onto. Normally the command will
+ of the commit you are rebasing onto. Normally non-interactive rebase will
exit with the message "Current branch is up to date" in such a
situation.
+ Incompatible with the --interactive option.
++
+You may find this (or --no-ff with an interactive rebase) helpful after
+reverting a topic branch merge, as this option recreates the topic branch with
+fresh commits so it can be remerged successfully without needing to "revert
+the reversion" (see the
+link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
--ignore-whitespace::
--whitespace=<option>::
--ignore-date::
These flags are passed to 'git am' to easily change the dates
of the rebased commits (see linkgit:git-am[1]).
+ Incompatible with the --interactive option.
-i::
--interactive::
-p::
--preserve-merges::
Instead of ignoring merges, try to recreate them.
++
+This uses the `--interactive` machinery internally, but combining it
+with the `--interactive` option explicitly is generally not a good
+idea unless you know what you are doing (see BUGS below).
+
--root::
Rebase all commits reachable from <branch>, instead of
root commits will be rewritten to have <newbase> as parent
instead.
+--autosquash::
+ When the commit log message begins with "squash! ..." (or
+ "fixup! ..."), and there is a commit whose title begins with
+ the same ..., automatically modify the todo list of rebase -i
+ so that the commit marked for squashing comes right after the
+ commit to be modified, and change the action of the moved
+ commit from `pick` to `squash` (or `fixup`).
++
+This option is only valid when the '--interactive' option is used.
+
+--no-ff::
+ With --interactive, cherry-pick all rebased commits instead of
+ fast-forwarding over the unchanged ones. This ensures that the
+ entire history of the rebased branch is composed of new commits.
++
+Without --interactive, this is a synonym for --force-rebase.
++
+You may find this helpful after reverting a topic branch merge, as this option
+recreates the topic branch with fresh commits so it can be remerged
+successfully without needing to "revert the reversion" (see the
+link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
+
include::merge-strategies.txt[]
NOTES
command "pick" with the command "reword".
If you want to fold two or more commits into one, replace the command
-"pick" with "squash" for the second and subsequent commit. If the
-commits had different authors, it will attribute the squashed commit to
-the author of the first commit.
+"pick" for the second and subsequent commits with "squash" or "fixup".
+If the commits had different authors, the folded commit will be
+attributed to the author of the first commit. The suggested commit
+message for the folded commit is the concatenation of the commit
+messages of the first commit and of those with the "squash" command,
+but omits the commit messages of commits with the "fixup" command.
'git rebase' will stop when "pick" has been replaced with "edit" or
when a command fails due to merge errors. When you are done editing
$ git rebase -i -p --onto Q O
-----------------------------
+Reordering and editing commits usually creates untested intermediate
+steps. You may want to check that your history editing did not break
+anything by running a test, or at least recompiling at intermediate
+points in history by using the "exec" command (shortcut "x"). You may
+do so by creating a todo list like this one:
+
+-------------------------------------------
+pick deadbee Implement feature XXX
+fixup f1a5c00 Fix to feature XXX
+exec make
+pick c0ffeee The oneline of the next commit
+edit deadbab The oneline of the commit after
+exec cd subdir; make test
+...
+-------------------------------------------
+
+The interactive rebase will stop when a command fails (i.e. exits with
+non-0 status) to give you an opportunity to fix the problem. You can
+continue with `git rebase --continue`.
+
+The "exec" command launches the command in a shell (the one specified
+in `$SHELL`, or the default shell if `$SHELL` is not set), so you can
+use shell features (like "cd", ">", ";" ...). The command is run from
+the root of the working tree.
SPLITTING COMMITS
-----------------
Hard case: The changes are not the same.::
This happens if the 'subsystem' rebase had conflicts, or used
- `\--interactive` to omit, edit, or squash 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`.
case" recovery too!
+BUGS
+----
+The todo list presented by `--preserve-merges --interactive` does not
+represent the topology of the revision graph. Editing commits and
+rewording their commit messages should work fine, but attempts to
+reorder commits tend to produce counterintuitive results.
+
+For example, an attempt to rearrange
+------------
+1 --- 2 --- 3 --- 4 --- 5
+------------
+to
+------------
+1 --- 2 --- 4 --- 3 --- 5
+------------
+by moving the "pick 4" line will result in the following history:
+------------
+ 3
+ /
+1 --- 2 --- 4 --- 5
+------------
+
Authors
------
Written by Junio C Hamano <gitster@pobox.com> and