+
See also INCOMPATIBLE OPTIONS below.
+--rerere-autoupdate::
+--no-rerere-autoupdate::
+ Allow the rerere mechanism to update the index with the
+ result of auto-conflict resolution if possible.
+
-S[<keyid>]::
--gpg-sign[=<keyid>]::
GPG-sign commits. The `keyid` argument is optional and
+
By default, or when `no-rebase-cousins` was specified, commits which do not
have `<upstream>` as direct ancestor will keep their original branch point,
-i.e. commits that would be excluded by gitlink:git-log[1]'s
+i.e. commits that would be excluded by linkgit:git-log[1]'s
`--ancestry-path` option will keep their original ancestry by default. If
the `rebase-cousins` mode is turned on, such commits are instead rebased
onto `<upstream>` (or `<onto>`, if specified).
+
-The `--rebase-merges` mode is similar in spirit to `--preserve-merges`, but
-in contrast to that option works well in interactive rebases: commits can be
-reordered, inserted and dropped at will.
+The `--rebase-merges` mode is similar in spirit to the deprecated
+`--preserve-merges`, but in contrast to that option works well in interactive
+rebases: commits can be reordered, inserted and dropped at will.
+
It is currently only possible to recreate the merge commits using the
`recursive` merge strategy; Different merge strategies can be used only via
-p::
--preserve-merges::
- Recreate merge commits instead of flattening the history by replaying
- commits a merge commit introduces. Merge conflict resolutions or manual
- amendments to merge commits are not preserved.
+ [DEPRECATED: use `--rebase-merges` instead] Recreate merge commits
+ instead of flattening the history by replaying commits a merge commit
+ introduces. Merge conflict resolutions or manual amendments to merge
+ commits are not preserved.
+
This uses the `--interactive` machinery internally, but combining it
with the `--interactive` option explicitly is generally not a good
INCOMPATIBLE OPTIONS
--------------------
-git-rebase has many flags that are incompatible with each other,
-predominantly due to the fact that it has three different underlying
-implementations:
-
- * one based on linkgit:git-am[1] (the default)
- * one based on git-merge-recursive (merge backend)
- * one based on linkgit:git-cherry-pick[1] (interactive backend)
-
-Flags only understood by the am backend:
+The following options:
* --committer-date-is-author-date
* --ignore-date
* --ignore-whitespace
* -C
-Flags understood by both merge and interactive backends:
+are incompatible with the following options:
* --merge
* --strategy
* --strategy-option
* --allow-empty-message
-
-Flags only understood by the interactive backend:
-
* --[no-]autosquash
* --rebase-merges
* --preserve-merges
* --interactive
* --exec
* --keep-empty
- * --autosquash
* --edit-todo
* --root when used in combination with --onto
-Other incompatible flag pairs:
+In addition, the following pairs of options are incompatible:
* --preserve-merges and --interactive
* --preserve-merges and --signoff
start with) or ended empty (all changes were already applied
upstream in other commits).
-The merge backend does the same.
-
The interactive backend drops commits by default that
started empty and halts if it hits a commit that ended up empty.
The `--keep-empty` option exists for the interactive backend to allow
Directory rename detection
~~~~~~~~~~~~~~~~~~~~~~~~~~
-The merge and interactive backends work fine with
-directory rename detection. The am backend sometimes does not.
+Directory rename heuristics are enabled in the merge and interactive
+backends. Due to the lack of accurate tree information, directory
+rename detection is disabled in the am backend.
include::merge-strategies.txt[]
At this time, the `merge` command will *always* use the `recursive`
merge strategy for regular merges, and `octopus` for octopus merges,
-strategy, with no way to choose a different one. To work around
+with no way to choose a different one. To work around
this, an `exec` command can be used to call `git merge` explicitly,
using the fact that the labels are worktree-local refs (the ref
`refs/rewritten/onto` would correspond to the label `onto`, for example).
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. Use
-`--rebase-merges` in such scenarios instead.
+The todo list presented by the deprecated `--preserve-merges --interactive`
+does not represent the topology of the revision graph (use `--rebase-merges`
+instead). Editing commits and rewording their commit messages should work
+fine, but attempts to reorder commits tend to produce counterintuitive results.
+Use `--rebase-merges` in such scenarios instead.
For example, an attempt to rearrange
------------