-If *--pretty* is specified, print the contents of the commit changesets
-in human-readable form.
-
-The *--objects* flag causes 'git-rev-list' to print the object IDs of
-any object referenced by the listed commits. 'git-rev-list --objects foo
-^bar' thus means "send me all object IDs which I need to download if
-I have the commit object 'bar', but not 'foo'".
-
-The *--bisect* flag limits output to the one commit object which is
-roughly halfway between the included and excluded commits. Thus,
-if "git-rev-list --bisect foo ^bar ^baz" outputs 'midpoint', the output
-of "git-rev-list foo ^midpoint" and "git-rev-list midpoint ^bar ^baz"
-would be of roughly the same length. Finding the change which introduces
-a regression is thus reduced to a binary search: repeatedly generate and
-test new 'midpoint's until the commit chain is of length one.
-
-If *--merge-order* is specified, the commit history is decomposed into a
-unique sequence of minimal, non-linear epochs and maximal, linear epochs.
-Non-linear epochs are then linearised by sorting them into merge order, which
-is described below.
-
+A special notation <commit1>..<commit2> can be used as a
+short-hand for {caret}<commit1> <commit2>.
+
+
+OPTIONS
+-------
+--pretty::
+ Print the contents of the commit changesets in human-readable form.
+
+--header::
+ Print the contents of the commit in raw-format; each
+ record is separated with a NUL character.
+
+--objects::
+ Print the object IDs of any object referenced by the listed commits.
+ 'git-rev-list --objects foo ^bar' thus means "send me all object IDs
+ which I need to download if I have the commit object 'bar', but
+ not 'foo'".
+
+--unpacked::
+ Only useful with `--objects`; print the object IDs that
+ are not in packs.
+
+--bisect::
+ Limit output to the one commit object which is roughly halfway
+ between the included and excluded commits. Thus, if 'git-rev-list
+ --bisect foo ^bar ^baz' outputs 'midpoint', the output
+ of 'git-rev-list foo ^midpoint' and 'git-rev-list midpoint
+ ^bar ^baz' would be of roughly the same length. Finding the change
+ which introduces a regression is thus reduced to a binary search:
+ repeatedly generate and test new 'midpoint's until the commit chain
+ is of length one.
+
+--max-count::
+ Limit the number of commits output.
+
+--max-age=timestamp, --min-age=timestamp::
+ Limit the commits output to specified time range.
+
+--sparse::
+ When optional paths are given, the command outputs only
+ the commits that changes at least one of them, and also
+ ignores merges that do not touch the given paths. This
+ flag makes the command output all eligible commits
+ (still subject to count and age limitation), but apply
+ merge simplification nevertheless.
+
+--all::
+ Pretend as if all the refs in `$GIT_DIR/refs/` are
+ listed on the command line as <commit>.
+
+--topo-order::
+ By default, the commits are shown in reverse
+ chronological order. This option makes them appear in
+ topological order (i.e. descendant commits are shown
+ before their parents).
+
+--merge-order::
+ When specified the commit history is decomposed into a unique
+ sequence of minimal, non-linear epochs and maximal, linear epochs.
+ Non-linear epochs are then linearised by sorting them into merge
+ order, which is described below.
++