CONFIGURATION
-------------
-include::rebase-config.txt[]
+include::config/rebase.txt[]
OPTIONS
-------
--exec <cmd>::
Append "exec <cmd>" after each line creating a commit in the
final history. <cmd> will be interpreted as one or more shell
- commands.
+ commands. Any command that fails will interrupt the rebase,
+ with exit code 1.
+
You may execute several commands by either using one instance of `--exec`
with several commands:
BEHAVIORAL DIFFERENCES
-----------------------
- * empty commits:
+ There are some subtle differences how the backends behave.
- am-based rebase will drop any "empty" commits, whether the
- commit started empty (had no changes relative to its parent to
- start with) or ended empty (all changes were already applied
- upstream in other commits).
+ Empty commits
+ ~~~~~~~~~~~~~
- merge-based rebase does the same.
+ The am backend drops any "empty" commits, regardless of whether the
+ commit started empty (had no changes relative to its parent to
+ start with) or ended empty (all changes were already applied
+ upstream in other commits).
- interactive-based rebase will by default drop commits that
- started empty and halt if it hits a commit that ended up empty.
- The `--keep-empty` option exists for interactive rebases to allow
- it to keep commits that started empty.
+ The merge backend does the same.
- * directory rename detection:
+ 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
+ it to keep commits that started empty.
- merge-based and interactive-based rebases work fine with
- directory rename detection. am-based rebases sometimes do not.
+ Directory rename detection
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ The merge and interactive backends work fine with
+ directory rename detection. The am backend sometimes does not.
include::merge-strategies.txt[]
the files and/or the commit message, amend the commit, and continue
rebasing.
+To interrupt the rebase (just like an "edit" command would do, but without
+cherry-picking any commit first), use the "break" command.
+
If you just want to edit the commit message for a commit, replace the
command "pick" with the command "reword".
case" recovery too!
REBASING MERGES
------------------
+---------------
The interactive rebase command was originally designed to handle
individual patch series. As such, it makes sense to exclude merge
to proceed.
The `reset` command resets the HEAD, index and worktree to the specified
-revision. It is isimilar to an `exec git reset --hard <label>`, but
+revision. It is similar to an `exec git reset --hard <label>`, but
refuses to overwrite untracked files. If the `reset` command fails, it is
rescheduled immediately, with a helpful message how to edit the todo list
(this typically happens when a `reset` command was inserted into the todo
list manually and contains a typo).
-The `merge` command will merge the specified revision into whatever is
-HEAD at that time. With `-C <original-commit>`, the commit message of
+The `merge` command will merge the specified revision(s) into whatever
+is HEAD at that time. With `-C <original-commit>`, the commit message of
the specified merge commit will be used. When the `-C` is changed to
a lower-case `-c`, the message will be opened in an editor after a
successful merge so that the user can edit the message.
when the merge operation did not even start), it is rescheduled immediately.
At this time, the `merge` command will *always* use the `recursive`
-merge strategy, with no way to choose a different one. To work around
+merge strategy for regular merges, and `octopus` for octopus merges,
+strategy, 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).