<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
+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.
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.
$ 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
-----------------