Make a list of the commits which are about to be rebased.  Let the
	user edit that list before rebasing.  This mode can also be used to
	split commits (see SPLITTING COMMITS below).
+
The commit list format can be changed by setting the configuration option
rebase.instructionFormat.  A customized instruction format will automatically
have the commit hash prepended to the format.
+
See also INCOMPATIBLE OPTIONS below.

-r::
--rebase-merges[=(rebase-cousins|no-rebase-cousins)]::
--no-rebase-merges::
	By default, a rebase will simply drop merge commits from the todo
	list, and put the rebased commits into a single, linear branch.
	With `--rebase-merges`, the rebase will instead try to preserve
	the branching structure within the commits that are to be rebased,
	by recreating the merge commits. Any resolved merge conflicts or
	manual amendments in these merge commits will have to be
	resolved/re-applied manually. `--no-rebase-merges` can be used to
	countermand both the `rebase.rebaseMerges` config option and a previous
	`--rebase-merges`.
+
When rebasing merges, there are two modes: `rebase-cousins` and
`no-rebase-cousins`. If the mode is not specified, it defaults to
`no-rebase-cousins`. In `no-rebase-cousins` mode, commits which do not have
`<upstream>` as direct ancestor will keep their original branch point, i.e.
commits that would be excluded by linkgit:git-log[1]'s `--ancestry-path`
option will keep their original ancestry by default. In `rebase-cousins` mode,
such commits are instead rebased onto `<upstream>` (or `<onto>`, if
specified).
+
It is currently only possible to recreate the merge commits using the
`ort` merge strategy; different merge strategies can be used only via
explicit `exec git merge -s <strategy> [...]` commands.
+
See also REBASING MERGES and INCOMPATIBLE OPTIONS below.

-x <cmd>::
--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. 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:
+
	git rebase -i --exec "cmd1 && cmd2 && ..."
+
or by giving more than one `--exec`:
+
	git rebase -i --exec "cmd1" --exec "cmd2" --exec ...
+
If `--autosquash` is used, `exec` lines will not be appended for
the intermediate commits, and will only appear at the end of each
squash/fixup series.
+
This uses the `--interactive` machinery internally, but it can be run
without an explicit `--interactive`.
+
See also INCOMPATIBLE OPTIONS below.

--root::
	Rebase all commits reachable from `<branch>`, instead of
	limiting them with an `<upstream>`.  This allows you to rebase
	the root commit(s) on a branch.
+
See also INCOMPATIBLE OPTIONS below.

--autosquash::
--no-autosquash::
	Automatically squash commits with specially formatted messages into
	previous commits being rebased.  If a commit message starts with
	"squash! ", "fixup! " or "amend! ", the remainder of the title
	is taken as a commit specifier, which matches a previous commit if it
	matches the title or the hash of that commit.  If no commit
	matches fully, matches of the specifier with the start of commit
	titles are considered.
+
In the rebase todo list, the actions of squash, fixup and amend commits are
changed from `pick` to `squash`, `fixup` or `fixup -C`, respectively, and they
are moved right after the commit they modify.  The `--interactive` option can
be used to review and edit the todo list before proceeding.
+
The recommended way to create commits with squash markers is by using the
`--squash`, `--fixup`, `--fixup=amend:` or `--fixup=reword:` options of
linkgit:git-commit[1], which take the target commit as an argument and
automatically fill in the title of the new commit from that.
+
Setting configuration variable `rebase.autoSquash` to true enables
auto-squashing by default for interactive rebase.  The `--no-autosquash`
option can be used to override