Ignoring a merge sounds like ignoring the changes a merge commit introduces altogether, as if the merge commit was skipped or dropped from history. But that is not what happens if this options is not specified. Instead, what happens is that the separate commits a merge commit introduces are replayed in order, and only any possible merge conflict resolutions are ignored. Get this straight in the docs. Also, do not say that merge commits are *tried* to be recreated. They are recreated, but possibly with conflicts, which in turn are likely to be different from any original conflicts. Still recreating a merge commit does not just silently fail in any case, which is how "try to recreate" might sound. Signed-off-by: Sebastian Schuberth <sschuberth@xxxxxxxxx> --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index d728030..3a6d139 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -362,7 +362,7 @@ default is `--no-fork-point`, otherwise the default is `--fork-point`. -p:: --preserve-merges:: - Instead of ignoring merges, try to recreate them. + Recreate merge commits instead of replaying commits a merge commit introduces. + This uses the `--interactive` machinery internally, but combining it with the `--interactive` option explicitly is generally not a good -- 1.9.5.msysgit.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html