against.  May be any valid commit,
	not just an existing branch name. Defaults to the configured
	upstream for the current branch.

<branch>::
	Working branch; defaults to `HEAD`.

--apply::
	Use applying strategies to rebase (calling `git-am`
	internally).  This option may become a no-op in the future
	once the merge backend handles everything the apply one does.
+
See also INCOMPATIBLE OPTIONS below.

--empty=(drop|keep|stop)::
	How to handle commits that are not empty to start and are not
	clean cherry-picks of any upstream commit, but which become
	empty after rebasing (because they contain a subset of already
	upstream changes):
+
--
`drop`;;
	The commit will be dropped. This is the default behavior.
`keep`;;
	The commit will be kept. This option is implied when `--exec` is
	specified unless `-i`/`--interactive` is also specified.
`stop`;;
`ask`;;
	The rebase will halt when the commit is applied, allowing you to
	choose whether to drop it, edit files more, or just commit the empty
	changes. This option is implied when `-i`/`--interactive` is
	specified. `ask` is a deprecated synonym of `stop`.
--
+
Note that commits which start empty are kept (unless `--no-keep-empty`
is specified), and commits which are clean cherry-picks (as determined
by `git log --cherry-mark ...`) are detected and dropped as a
preliminary step (unless `--reapply-cherry-picks` or `--keep-base` is
passed).
+
See also INCOMPATIBLE OPTIONS below.

--no-keep-empty::
--keep-empty::
	Do not keep commits that start empty before the rebase
	(i.e. that do not change anything from its parent) in the
	result.  The default is to keep commits which start empty,
	since creating such commits requires passing the `--allow-empty`
	override flag to `git commit`, signifying that a user is very
	intentionally creating such a commit and thus wants to keep
	it.
+
Usage of this flag will probably be rare, since you can get rid of
commits that start empty by just firing up an interactive rebase and
removing the lines corresponding to the commits you don't want.  This
flag exists as a convenient shortcut, such as for cases where external
tools generate many empty commits and you want them all removed.
+
For commits which do not start empty but become empty after rebasing,
see the `--empty` flag.
+
See also INCOMPATIBLE OPTIONS below.

--reapply-cherry-picks::
--no-reapply-cherry-picks::
	Reapply all clean cherry-picks of any upstream commit instead
	of preemptively dropping them. (If these commits then become
	empty after rebasing, because they contain a subset of already
	upstream changes, the behavior towards them is controlled by
	the `--empty` flag.)
+
In the absence of `--keep-base` (or if `--no-reapply-cherry-picks` is
given), these commits will be automatically dropped.  Because this
necessitates reading all upstream commits, this can be expensive in
repositories with a large number of upstream commits that need to be
read. When using the 'merge' backend, warnings will be issued for each
dropped commit (unless `--quiet` is given). Advice will also be issued
unless `advice.skippedCherryPicks` is set to false (see
linkgit:git-config[1]).
+
`--reapply-cherry-picks` allows rebase to forgo reading all upstream
commits, potentially improving performance.
+
See also INCOMPATIBLE OPTIONS below.

--allow-empty-message::
	No-op.  Rebasing commits with an empty message used to fail
	and this option would override that behavior, allowing commits
	with empty messages to be rebased.  Now commits with an empty
	message do not cause rebasing to halt.
+
See also INCOMPATIBLE OPTIONS below.

-m::
--merge::
	Using merging strategies to rebase (default).
+
Note that a rebase merge works by replaying each commit from the working
branch on top of the `<upstream>` branch.  Because of this, when a merge
conflict happens, the side reported as 'ours' is the so-far rebased
series, starting with `<upstream>`, and 'theirs' is the working branch.
In other words, the sides are swapped.
+
See also INCOMPATIBLE