Merge branch 'jc/rev-list-options-fix'

* jc/rev-list-options-fix:
"log --cherry-pick" documentation regression fix

diff --combined Documentation/rev-list-options.txt
index ea5c6c49bd1b673aba48c057add1b5d15ae840a0,a9de9a74dc71e71e776cf1b7acd667d5c01582f7..73111bb0512476cb1d1786d65c416b7f4efd94cf
--- 1/Documentation/rev-list-options.txt
--- 2/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@@ -72,26 -72,11 +72,26 @@@ endif::git-rev-list[
  
  --merges::
  
 -      Print only merge commits.
 +      Print only merge commits. This is exactly the same as `--min-parents=2`.
  
  --no-merges::
  
 -      Do not print commits with more than one parent.
 +      Do not print commits with more than one parent. This is
 +      exactly the same as `--max-parents=1`.
 +
 +--min-parents=<number>::
 +--max-parents=<number>::
 +--no-min-parents::
 +--no-max-parents::
 +
 +      Show only commits which have at least (or at most) that many
 +      commits. In particular, `--max-parents=1` is the same as `--no-merges`,
 +      `--min-parents=2` is the same as `--merges`.  `--max-parents=0`
 +      gives all root commits and `--min-parents=3` all octopus merges.
 ++
 +`--no-min-parents` and `--no-max-parents` reset these limits (to no limit)
 +again.  Equivalent forms are `--min-parents=0` (any commit has 0 or more
 +parents) and `--max-parents=-1` (negative numbers denote no upper limit).
  
  --first-parent::
        Follow only the first parent commit upon seeing a merge
@@@ -166,11 -151,6 +166,11 @@@ ifdef::git-rev-list[
        to /dev/null as the output does not have to be formatted.
  endif::git-rev-list[]
  
 +--cherry-mark::
 +
 +      Like `--cherry-pick` (see below) but mark equivalent commits
 +      with `=` rather than omitting them, and inequivalent ones with `+`.
 +
  --cherry-pick::
  
        Omit any commit that introduces the same change as
@@@ -179,33 -159,12 +179,33 @@@
  +
  For example, if you have two branches, `A` and `B`, a usual way
  to list all commits on only one side of them is with
- `--left-right`, like the example above in the description of
- that option.  It however shows the commits that were cherry-picked
+ `--left-right` (see the example below in the description of
+ the `--left-right` option).  It however shows the commits that were cherry-picked
  from the other branch (for example, "3rd on b" may be cherry-picked
  from branch A).  With this option, such pairs of commits are
  excluded from the output.
  
 +--left-only::
 +--right-only::
 +
 +      List only commits on the respective side of a symmetric range,
 +      i.e. only those which would be marked `<` resp. `>` by
 +      `--left-right`.
 ++
 +For example, `--cherry-pick --right-only A...B` omits those
 +commits from `B` which are in `A` or are patch-equivalent to a commit in
 +`A`. In other words, this lists the `{plus}` commits from `git cherry A B`.
 +More precisely, `--cherry-pick --right-only --no-merges` gives the exact
 +list.
 +
 +--cherry::
 +
 +      A synonym for `--right-only --cherry-mark --no-merges`; useful to
 +      limit the output to the commits on our side and mark those that
 +      have been applied to the other side of a forked history with
 +      `git log --cherry upstream...mybranch`, similar to
 +      `git cherry upstream mybranch`.
 +
  -g::
  --walk-reflogs::