fast-forwarding
	over the unchanged ones.  This ensures that the entire history of
	the rebased branch is composed of new commits.
+
You may find this helpful after reverting a topic branch merge, as this option
recreates the topic branch with fresh commits so it can be remerged
successfully without needing to "revert the reversion" (see the
link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for
details).

--fork-point::
--no-fork-point::
	Use reflog to find a better common ancestor between `<upstream>`
	and `<branch>` when calculating which commits have been
	introduced by `<branch>`.
+
When `--fork-point` is active, 'fork_point' will be used instead of
`<upstream>` to calculate the set of commits to rebase, where
'fork_point' is the result of `git merge-base --fork-point <upstream>
<branch>` command (see linkgit:git-merge-base[1]).  If 'fork_point'
ends up being empty, the `<upstream>` will be used as a fallback.
+
If `<upstream>` or `--keep-base` is given on the command line, then
the default is `--no-fork-point`, otherwise the default is
`--fork-point`. See also `rebase.forkpoint` in linkgit:git-config[1].
+
If your branch was based on `<upstream>` but `<upstream>` was rewound and
your branch contains commits which were dropped, this option can be used
with `--keep-base` in order to drop those commits from your branch.
+
See also INCOMPATIBLE OPTIONS below.

--ignore-whitespace::
	Ignore whitespace differences when trying to reconcile
	differences. Currently, each backend implements an approximation of
	this behavior:
+
apply backend;;
	When applying a patch, ignore changes in whitespace in context
	lines. Unfortunately, this means that if the "old" lines being
	replaced by the patch differ only in whitespace from the existing
	file, you will get a merge conflict instead of a successful patch
	application.
+
merge backend;;
	Treat lines with only whitespace changes as unchanged when merging.
	Unfortunately, this means that any patch hunks that were intended
	to modify whitespace and nothing else will be dropped, even if the
	other side had no changes that conflicted.

--whitespace=<option>::
	This flag is passed to the `git apply` program
	(see linkgit:git-apply[1]) that applies the patch.
	Implies `--apply`.
+
See also INCOMPATIBLE OPTIONS below.

--committer-date-is-author-date::
	Instead of using the current time as the committer date, use
	the author date of the commit being rebased as the committer
	date. This option implies `--force-rebase`.

--ignore-date::
--reset-author-date::
	Instead of using the author date of the original commit, use
	the current time as the	author date of the rebased commit.  This
	option implies `--force-rebase`.
+
See also INCOMPATIBLE OPTIONS below.

--signoff::
	Add a `Signed-off-by` trailer to all the rebased commits. Note
	that if `--interactive` is given then only commits marked to be
	picked, edited or reworded will have the trailer added.
+
See also INCOMPATIBLE OPTIONS below.

-i::
--interactive::
	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`