Merge branch 'sr/local-config'
[gitweb.git] / Documentation / git-rebase.txt
index 50ba2e469f48f1bc16c3f6e3b6f6451a9e29637a..b4314568f5a742d186e69b97f782193d2883e6b3 100644 (file)
@@ -250,6 +250,13 @@ on top of the <upstream> branch using the given strategy, using
 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.
@@ -310,6 +317,11 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
 -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
@@ -611,6 +623,28 @@ The ripple effect of a "hard case" recovery is especially bad:
 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