Merge branch 'jk/commit-author-parsing'

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 94e07fdab550dcac70734fb79724b00cf8d23edc..f14100a16022306d280221b3cb1ae88f8c5498ce 100644 (file)
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -281,6 +281,10 @@ which makes little sense.
        specified, `-s recursive`.  Note the reversal of 'ours' and
        'theirs' as noted above for the `-m` option.
 
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+       GPG-sign commits.
+
 -q::
 --quiet::
        Be quiet. Implies --no-stat.
@@ -312,11 +316,8 @@ which makes little sense.
 
 -f::
 --force-rebase::
-       Force the rebase even if the current branch is a descendant
-       of the commit you are rebasing onto.  Normally non-interactive rebase will
-       exit with the message "Current branch is up to date" in such a
-       situation.
-       Incompatible with the --interactive option.
+       Force a rebase even if the current branch is up-to-date and
+       the command without `--force` would return without doing anything.
 +
 You may find this (or --no-ff with an interactive rebase) helpful after
 reverting a topic branch merge, as this option recreates the topic branch with
@@ -324,6 +325,16 @@ 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 'git merge-base --fork-point' to find a better common ancestor
+       between `upstream` and `branch` when calculating which commits have
+       have been introduced by `branch` (see linkgit:git-merge-base[1]).
++
+If no non-option arguments are given on the command line, then the default is
+`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally
+unless the `--fork-point` option is specified.
+
 --ignore-whitespace::
 --whitespace=<option>::
        These flag are passed to the 'git apply' program