cebba62239ad8861160e79255fdbdc4800be5e05
   1Commit Formatting
   2~~~~~~~~~~~~~~~~~
   3
   4ifdef::git-rev-list[]
   5Using these options, linkgit:git-rev-list[1] will act similar to the
   6more specialized family of commit log tools: linkgit:git-log[1],
   7linkgit:git-show[1], and linkgit:git-whatchanged[1]
   8endif::git-rev-list[]
   9
  10include::pretty-options.txt[]
  11
  12--relative-date::
  13
  14        Synonym for `--date=relative`.
  15
  16--date=(relative|local|default|iso|rfc|short|raw)::
  17
  18        Only takes effect for dates shown in human-readable format, such
  19        as when using "--pretty". `log.date` config variable sets a default
  20        value for log command's --date option.
  21+
  22`--date=relative` shows dates relative to the current time,
  23e.g. "2 hours ago".
  24+
  25`--date=local` shows timestamps in user's local timezone.
  26+
  27`--date=iso` (or `--date=iso8601`) shows timestamps in ISO 8601 format.
  28+
  29`--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822
  30format, often found in E-mail messages.
  31+
  32`--date=short` shows only date but not time, in `YYYY-MM-DD` format.
  33+
  34`--date=raw` shows the date in the internal raw git format `%s %z` format.
  35+
  36`--date=default` shows timestamps in the original timezone
  37(either committer's or author's).
  38
  39ifdef::git-rev-list[]
  40--header::
  41
  42        Print the contents of the commit in raw-format; each record is
  43        separated with a NUL character.
  44endif::git-rev-list[]
  45
  46--parents::
  47
  48        Print also the parents of the commit (in the form "commit parent...").
  49        Also enables parent rewriting, see 'History Simplification' below.
  50
  51--children::
  52
  53        Print also the children of the commit (in the form "commit child...").
  54        Also enables parent rewriting, see 'History Simplification' below.
  55
  56ifdef::git-rev-list[]
  57--timestamp::
  58        Print the raw commit timestamp.
  59endif::git-rev-list[]
  60
  61--left-right::
  62
  63        Mark which side of a symmetric diff a commit is reachable from.
  64        Commits from the left side are prefixed with `<` and those from
  65        the right with `>`.  If combined with `--boundary`, those
  66        commits are prefixed with `-`.
  67+
  68For example, if you have this topology:
  69+
  70-----------------------------------------------------------------------
  71             y---b---b  branch B
  72            / \ /
  73           /   .
  74          /   / \
  75         o---x---a---a  branch A
  76-----------------------------------------------------------------------
  77+
  78you would get an output like this:
  79+
  80-----------------------------------------------------------------------
  81        $ git rev-list --left-right --boundary --pretty=oneline A...B
  82
  83        >bbbbbbb... 3rd on b
  84        >bbbbbbb... 2nd on b
  85        <aaaaaaa... 3rd on a
  86        <aaaaaaa... 2nd on a
  87        -yyyyyyy... 1st on b
  88        -xxxxxxx... 1st on a
  89-----------------------------------------------------------------------
  90
  91--graph::
  92
  93        Draw a text-based graphical representation of the commit history
  94        on the left hand side of the output.  This may cause extra lines
  95        to be printed in between commits, in order for the graph history
  96        to be drawn properly.
  97+
  98This enables parent rewriting, see 'History Simplification' below.
  99+
 100This implies the '--topo-order' option by default, but the
 101'--date-order' option may also be specified.
 102
 103ifdef::git-rev-list[]
 104--count::
 105        Print a number stating how many commits would have been
 106        listed, and suppress all other output.  When used together
 107        with '--left-right', instead print the counts for left and
 108        right commits, separated by a tab.
 109endif::git-rev-list[]
 110
 111
 112ifndef::git-rev-list[]
 113Diff Formatting
 114~~~~~~~~~~~~~~~
 115
 116Below are listed options that control the formatting of diff output.
 117Some of them are specific to linkgit:git-rev-list[1], however other diff
 118options may be given. See linkgit:git-diff-files[1] for more options.
 119
 120-c::
 121
 122        With this option, diff output for a merge commit
 123        shows the differences from each of the parents to the merge result
 124        simultaneously instead of showing pairwise diff between a parent
 125        and the result one at a time. Furthermore, it lists only files
 126        which were modified from all parents.
 127
 128--cc::
 129
 130        This flag implies the '-c' options and further compresses the
 131        patch output by omitting uninteresting hunks whose contents in
 132        the parents have only two variants and the merge result picks
 133        one of them without modification.
 134
 135-m::
 136
 137        This flag makes the merge commits show the full diff like
 138        regular commits; for each merge parent, a separate log entry
 139        and diff is generated. An exception is that only diff against
 140        the first parent is shown when '--first-parent' option is given;
 141        in that case, the output represents the changes the merge
 142        brought _into_ the then-current branch.
 143
 144-r::
 145
 146        Show recursive diffs.
 147
 148-t::
 149
 150        Show the tree objects in the diff output. This implies '-r'.
 151
 152-s::
 153        Suppress diff output.
 154endif::git-rev-list[]
 155
 156Commit Limiting
 157~~~~~~~~~~~~~~~
 158
 159Besides specifying a range of commits that should be listed using the
 160special notations explained in the description, additional commit
 161limiting may be applied.
 162
 163--
 164
 165-n 'number'::
 166--max-count=<number>::
 167
 168        Limit the number of commits output.
 169
 170--skip=<number>::
 171
 172        Skip 'number' commits before starting to show the commit output.
 173
 174--since=<date>::
 175--after=<date>::
 176
 177        Show commits more recent than a specific date.
 178
 179--until=<date>::
 180--before=<date>::
 181
 182        Show commits older than a specific date.
 183
 184ifdef::git-rev-list[]
 185--max-age=<timestamp>::
 186--min-age=<timestamp>::
 187
 188        Limit the commits output to specified time range.
 189endif::git-rev-list[]
 190
 191--author=<pattern>::
 192--committer=<pattern>::
 193
 194        Limit the commits output to ones with author/committer
 195        header lines that match the specified pattern (regular expression).
 196
 197--grep=<pattern>::
 198
 199        Limit the commits output to ones with log message that
 200        matches the specified pattern (regular expression).
 201
 202--all-match::
 203        Limit the commits output to ones that match all given --grep,
 204        --author and --committer instead of ones that match at least one.
 205
 206-i::
 207--regexp-ignore-case::
 208
 209        Match the regexp limiting patterns without regard to letters case.
 210
 211-E::
 212--extended-regexp::
 213
 214        Consider the limiting patterns to be extended regular expressions
 215        instead of the default basic regular expressions.
 216
 217-F::
 218--fixed-strings::
 219
 220        Consider the limiting patterns to be fixed strings (don't interpret
 221        pattern as a regular expression).
 222
 223--remove-empty::
 224
 225        Stop when a given path disappears from the tree.
 226
 227--merges::
 228
 229        Print only merge commits.
 230
 231--no-merges::
 232
 233        Do not print commits with more than one parent.
 234
 235--first-parent::
 236        Follow only the first parent commit upon seeing a merge
 237        commit.  This option can give a better overview when
 238        viewing the evolution of a particular topic branch,
 239        because merges into a topic branch tend to be only about
 240        adjusting to updated upstream from time to time, and
 241        this option allows you to ignore the individual commits
 242        brought in to your history by such a merge.
 243
 244--not::
 245
 246        Reverses the meaning of the '{caret}' prefix (or lack thereof)
 247        for all following revision specifiers, up to the next '--not'.
 248
 249--all::
 250
 251        Pretend as if all the refs in `refs/` are listed on the
 252        command line as '<commit>'.
 253
 254--branches[=<pattern>]::
 255
 256        Pretend as if all the refs in `refs/heads` are listed
 257        on the command line as '<commit>'. If '<pattern>' is given, limit
 258        branches to ones matching given shell glob. If pattern lacks '?',
 259        '*', or '[', '/*' at the end is implied.
 260
 261--tags[=<pattern>]::
 262
 263        Pretend as if all the refs in `refs/tags` are listed
 264        on the command line as '<commit>'. If '<pattern>' is given, limit
 265        tags to ones matching given shell glob. If pattern lacks '?', '*',
 266        or '[', '/*' at the end is implied.
 267
 268--remotes[=<pattern>]::
 269
 270        Pretend as if all the refs in `refs/remotes` are listed
 271        on the command line as '<commit>'. If '<pattern>' is given, limit
 272        remote-tracking branches to ones matching given shell glob.
 273        If pattern lacks '?', '*', or '[', '/*' at the end is implied.
 274
 275--glob=<glob-pattern>::
 276        Pretend as if all the refs matching shell glob '<glob-pattern>'
 277        are listed on the command line as '<commit>'. Leading 'refs/',
 278        is automatically prepended if missing. If pattern lacks '?', '*',
 279        or '[', '/*' at the end is implied.
 280
 281
 282ifndef::git-rev-list[]
 283--bisect::
 284
 285        Pretend as if the bad bisection ref `refs/bisect/bad`
 286        was listed and as if it was followed by `--not` and the good
 287        bisection refs `refs/bisect/good-*` on the command
 288        line.
 289endif::git-rev-list[]
 290
 291--stdin::
 292
 293        In addition to the '<commit>' listed on the command
 294        line, read them from the standard input. If a '--' separator is
 295        seen, stop reading commits and start reading paths to limit the
 296        result.
 297
 298ifdef::git-rev-list[]
 299--quiet::
 300
 301        Don't print anything to standard output.  This form
 302        is primarily meant to allow the caller to
 303        test the exit status to see if a range of objects is fully
 304        connected (or not).  It is faster than redirecting stdout
 305        to /dev/null as the output does not have to be formatted.
 306endif::git-rev-list[]
 307
 308--cherry-pick::
 309
 310        Omit any commit that introduces the same change as
 311        another commit on the "other side" when the set of
 312        commits are limited with symmetric difference.
 313+
 314For example, if you have two branches, `A` and `B`, a usual way
 315to list all commits on only one side of them is with
 316`--left-right`, like the example above in the description of
 317that option.  It however shows the commits that were cherry-picked
 318from the other branch (for example, "3rd on b" may be cherry-picked
 319from branch A).  With this option, such pairs of commits are
 320excluded from the output.
 321
 322--left-only::
 323--right-only::
 324
 325        List only commits on the respective side of a symmetric range,
 326        i.e. only those which would be marked `<` resp. `>` by
 327        `--left-right`.
 328+
 329For example, `--cherry-pick --right-only A...B` omits those
 330commits from `B` which are in `A` or are patch-equivalent to a commit in
 331`A`. In other words, this lists the `{plus}` commits from `git cherry A B`.
 332More precisely, `--cherry-pick --right-only --no-merges` gives the exact
 333list.
 334
 335-g::
 336--walk-reflogs::
 337
 338        Instead of walking the commit ancestry chain, walk
 339        reflog entries from the most recent one to older ones.
 340        When this option is used you cannot specify commits to
 341        exclude (that is, '{caret}commit', 'commit1..commit2',
 342        nor 'commit1\...commit2' notations cannot be used).
 343+
 344With '\--pretty' format other than oneline (for obvious reasons),
 345this causes the output to have two extra lines of information
 346taken from the reflog.  By default, 'commit@\{Nth}' notation is
 347used in the output.  When the starting commit is specified as
 348'commit@\{now}', output also uses 'commit@\{timestamp}' notation
 349instead.  Under '\--pretty=oneline', the commit message is
 350prefixed with this information on the same line.
 351This option cannot be combined with '\--reverse'.
 352See also linkgit:git-reflog[1].
 353
 354--merge::
 355
 356        After a failed merge, show refs that touch files having a
 357        conflict and don't exist on all heads to merge.
 358
 359--boundary::
 360
 361        Output uninteresting commits at the boundary, which are usually
 362        not shown.
 363
 364--
 365
 366History Simplification
 367~~~~~~~~~~~~~~~~~~~~~~
 368
 369Sometimes you are only interested in parts of the history, for example the
 370commits modifying a particular <path>. But there are two parts of
 371'History Simplification', one part is selecting the commits and the other
 372is how to do it, as there are various strategies to simplify the history.
 373
 374The following options select the commits to be shown:
 375
 376<paths>::
 377
 378        Commits modifying the given <paths> are selected.
 379
 380--simplify-by-decoration::
 381
 382        Commits that are referred by some branch or tag are selected.
 383
 384Note that extra commits can be shown to give a meaningful history.
 385
 386The following options affect the way the simplification is performed:
 387
 388Default mode::
 389
 390        Simplifies the history to the simplest history explaining the
 391        final state of the tree. Simplest because it prunes some side
 392        branches if the end result is the same (i.e. merging branches
 393        with the same content)
 394
 395--full-history::
 396
 397        As the default mode but does not prune some history.
 398
 399--dense::
 400
 401        Only the selected commits are shown, plus some to have a
 402        meaningful history.
 403
 404--sparse::
 405
 406        All commits in the simplified history are shown.
 407
 408--simplify-merges::
 409
 410        Additional option to '--full-history' to remove some needless
 411        merges from the resulting history, as there are no selected
 412        commits contributing to this merge.
 413
 414--ancestry-path::
 415
 416        When given a range of commits to display (e.g. 'commit1..commit2'
 417        or 'commit2 {caret}commit1'), only display commits that exist
 418        directly on the ancestry chain between the 'commit1' and
 419        'commit2', i.e. commits that are both descendants of 'commit1',
 420        and ancestors of 'commit2'.
 421
 422A more detailed explanation follows.
 423
 424Suppose you specified `foo` as the <paths>.  We shall call commits
 425that modify `foo` !TREESAME, and the rest TREESAME.  (In a diff
 426filtered for `foo`, they look different and equal, respectively.)
 427
 428In the following, we will always refer to the same example history to
 429illustrate the differences between simplification settings.  We assume
 430that you are filtering for a file `foo` in this commit graph:
 431-----------------------------------------------------------------------
 432          .-A---M---N---O---P
 433         /     /   /   /   /
 434        I     B   C   D   E
 435         \   /   /   /   /
 436          `-------------'
 437-----------------------------------------------------------------------
 438The horizontal line of history A--P is taken to be the first parent of
 439each merge.  The commits are:
 440
 441* `I` is the initial commit, in which `foo` exists with contents
 442  "asdf", and a file `quux` exists with contents "quux".  Initial
 443  commits are compared to an empty tree, so `I` is !TREESAME.
 444
 445* In `A`, `foo` contains just "foo".
 446
 447* `B` contains the same change as `A`.  Its merge `M` is trivial and
 448  hence TREESAME to all parents.
 449
 450* `C` does not change `foo`, but its merge `N` changes it to "foobar",
 451  so it is not TREESAME to any parent.
 452
 453* `D` sets `foo` to "baz".  Its merge `O` combines the strings from
 454  `N` and `D` to "foobarbaz"; i.e., it is not TREESAME to any parent.
 455
 456* `E` changes `quux` to "xyzzy", and its merge `P` combines the
 457  strings to "quux xyzzy".  Despite appearing interesting, `P` is
 458  TREESAME to all parents.
 459
 460'rev-list' walks backwards through history, including or excluding
 461commits based on whether '\--full-history' and/or parent rewriting
 462(via '\--parents' or '\--children') are used.  The following settings
 463are available.
 464
 465Default mode::
 466
 467        Commits are included if they are not TREESAME to any parent
 468        (though this can be changed, see '\--sparse' below).  If the
 469        commit was a merge, and it was TREESAME to one parent, follow
 470        only that parent.  (Even if there are several TREESAME
 471        parents, follow only one of them.)  Otherwise, follow all
 472        parents.
 473+
 474This results in:
 475+
 476-----------------------------------------------------------------------
 477          .-A---N---O
 478         /     /   /
 479        I---------D
 480-----------------------------------------------------------------------
 481+
 482Note how the rule to only follow the TREESAME parent, if one is
 483available, removed `B` from consideration entirely.  `C` was
 484considered via `N`, but is TREESAME.  Root commits are compared to an
 485empty tree, so `I` is !TREESAME.
 486+
 487Parent/child relations are only visible with --parents, but that does
 488not affect the commits selected in default mode, so we have shown the
 489parent lines.
 490
 491--full-history without parent rewriting::
 492
 493        This mode differs from the default in one point: always follow
 494        all parents of a merge, even if it is TREESAME to one of them.
 495        Even if more than one side of the merge has commits that are
 496        included, this does not imply that the merge itself is!  In
 497        the example, we get
 498+
 499-----------------------------------------------------------------------
 500        I  A  B  N  D  O
 501-----------------------------------------------------------------------
 502+
 503`P` and `M` were excluded because they are TREESAME to a parent.  `E`,
 504`C` and `B` were all walked, but only `B` was !TREESAME, so the others
 505do not appear.
 506+
 507Note that without parent rewriting, it is not really possible to talk
 508about the parent/child relationships between the commits, so we show
 509them disconnected.
 510
 511--full-history with parent rewriting::
 512
 513        Ordinary commits are only included if they are !TREESAME
 514        (though this can be changed, see '\--sparse' below).
 515+
 516Merges are always included.  However, their parent list is rewritten:
 517Along each parent, prune away commits that are not included
 518themselves.  This results in
 519+
 520-----------------------------------------------------------------------
 521          .-A---M---N---O---P
 522         /     /   /   /   /
 523        I     B   /   D   /
 524         \   /   /   /   /
 525          `-------------'
 526-----------------------------------------------------------------------
 527+
 528Compare to '\--full-history' without rewriting above.  Note that `E`
 529was pruned away because it is TREESAME, but the parent list of P was
 530rewritten to contain `E`'s parent `I`.  The same happened for `C` and
 531`N`.  Note also that `P` was included despite being TREESAME.
 532
 533In addition to the above settings, you can change whether TREESAME
 534affects inclusion:
 535
 536--dense::
 537
 538        Commits that are walked are included if they are not TREESAME
 539        to any parent.
 540
 541--sparse::
 542
 543        All commits that are walked are included.
 544+
 545Note that without '\--full-history', this still simplifies merges: if
 546one of the parents is TREESAME, we follow only that one, so the other
 547sides of the merge are never walked.
 548
 549--simplify-merges::
 550
 551        First, build a history graph in the same way that
 552        '\--full-history' with parent rewriting does (see above).
 553+
 554Then simplify each commit `C` to its replacement `C'` in the final
 555history according to the following rules:
 556+
 557--
 558* Set `C'` to `C`.
 559+
 560* Replace each parent `P` of `C'` with its simplification `P'`.  In
 561  the process, drop parents that are ancestors of other parents, and
 562  remove duplicates.
 563+
 564* If after this parent rewriting, `C'` is a root or merge commit (has
 565  zero or >1 parents), a boundary commit, or !TREESAME, it remains.
 566  Otherwise, it is replaced with its only parent.
 567--
 568+
 569The effect of this is best shown by way of comparing to
 570'\--full-history' with parent rewriting.  The example turns into:
 571+
 572-----------------------------------------------------------------------
 573          .-A---M---N---O
 574         /     /       /
 575        I     B       D
 576         \   /       /
 577          `---------'
 578-----------------------------------------------------------------------
 579+
 580Note the major differences in `N` and `P` over '\--full-history':
 581+
 582--
 583* `N`'s parent list had `I` removed, because it is an ancestor of the
 584  other parent `M`.  Still, `N` remained because it is !TREESAME.
 585+
 586* `P`'s parent list similarly had `I` removed.  `P` was then
 587  removed completely, because it had one parent and is TREESAME.
 588--
 589
 590Finally, there is a fifth simplification mode available:
 591
 592--ancestry-path::
 593
 594        Limit the displayed commits to those directly on the ancestry
 595        chain between the "from" and "to" commits in the given commit
 596        range. I.e. only display commits that are ancestor of the "to"
 597        commit, and descendants of the "from" commit.
 598+
 599As an example use case, consider the following commit history:
 600+
 601-----------------------------------------------------------------------
 602            D---E-------F
 603           /     \       \
 604          B---C---G---H---I---J
 605         /                     \
 606        A-------K---------------L--M
 607-----------------------------------------------------------------------
 608+
 609A regular 'D..M' computes the set of commits that are ancestors of `M`,
 610but excludes the ones that are ancestors of `D`. This is useful to see
 611what happened to the history leading to `M` since `D`, in the sense
 612that "what does `M` have that did not exist in `D`". The result in this
 613example would be all the commits, except `A` and `B` (and `D` itself,
 614of course).
 615+
 616When we want to find out what commits in `M` are contaminated with the
 617bug introduced by `D` and need fixing, however, we might want to view
 618only the subset of 'D..M' that are actually descendants of `D`, i.e.
 619excluding `C` and `K`. This is exactly what the '\--ancestry-path'
 620option does. Applied to the 'D..M' range, it results in:
 621+
 622-----------------------------------------------------------------------
 623                E-------F
 624                 \       \
 625                  G---H---I---J
 626                               \
 627                                L--M
 628-----------------------------------------------------------------------
 629
 630The '\--simplify-by-decoration' option allows you to view only the
 631big picture of the topology of the history, by omitting commits
 632that are not referenced by tags.  Commits are marked as !TREESAME
 633(in other words, kept after history simplification rules described
 634above) if (1) they are referenced by tags, or (2) they change the
 635contents of the paths given on the command line.  All other
 636commits are marked as TREESAME (subject to be simplified away).
 637
 638ifdef::git-rev-list[]
 639Bisection Helpers
 640~~~~~~~~~~~~~~~~~
 641
 642--bisect::
 643
 644Limit output to the one commit object which is roughly halfway between
 645included and excluded commits. Note that the bad bisection ref
 646`refs/bisect/bad` is added to the included commits (if it
 647exists) and the good bisection refs `refs/bisect/good-*` are
 648added to the excluded commits (if they exist). Thus, supposing there
 649are no refs in `refs/bisect/`, if
 650
 651-----------------------------------------------------------------------
 652        $ git rev-list --bisect foo ^bar ^baz
 653-----------------------------------------------------------------------
 654
 655outputs 'midpoint', the output of the two commands
 656
 657-----------------------------------------------------------------------
 658        $ git rev-list foo ^midpoint
 659        $ git rev-list midpoint ^bar ^baz
 660-----------------------------------------------------------------------
 661
 662would be of roughly the same length.  Finding the change which
 663introduces a regression is thus reduced to a binary search: repeatedly
 664generate and test new 'midpoint's until the commit chain is of length
 665one.
 666
 667--bisect-vars::
 668
 669This calculates the same as `--bisect`, except that refs in
 670`refs/bisect/` are not used, and except that this outputs
 671text ready to be eval'ed by the shell. These lines will assign the
 672name of the midpoint revision to the variable `bisect_rev`, and the
 673expected number of commits to be tested after `bisect_rev` is tested
 674to `bisect_nr`, the expected number of commits to be tested if
 675`bisect_rev` turns out to be good to `bisect_good`, the expected
 676number of commits to be tested if `bisect_rev` turns out to be bad to
 677`bisect_bad`, and the number of commits we are bisecting right now to
 678`bisect_all`.
 679
 680--bisect-all::
 681
 682This outputs all the commit objects between the included and excluded
 683commits, ordered by their distance to the included and excluded
 684commits. Refs in `refs/bisect/` are not used. The farthest
 685from them is displayed first. (This is the only one displayed by
 686`--bisect`.)
 687+
 688This is useful because it makes it easy to choose a good commit to
 689test when you want to avoid to test some of them for some reason (they
 690may not compile for example).
 691+
 692This option can be used along with `--bisect-vars`, in this case,
 693after all the sorted commit objects, there will be the same text as if
 694`--bisect-vars` had been used alone.
 695endif::git-rev-list[]
 696
 697
 698Commit Ordering
 699~~~~~~~~~~~~~~~
 700
 701By default, the commits are shown in reverse chronological order.
 702
 703--topo-order::
 704
 705        This option makes them appear in topological order (i.e.
 706        descendant commits are shown before their parents).
 707
 708--date-order::
 709
 710        This option is similar to '--topo-order' in the sense that no
 711        parent comes before all of its children, but otherwise things
 712        are still ordered in the commit timestamp order.
 713
 714--reverse::
 715
 716        Output the commits in reverse order.
 717        Cannot be combined with '\--walk-reflogs'.
 718
 719Object Traversal
 720~~~~~~~~~~~~~~~~
 721
 722These options are mostly targeted for packing of git repositories.
 723
 724--objects::
 725
 726        Print the object IDs of any object referenced by the listed
 727        commits.  '--objects foo ^bar' thus means "send me
 728        all object IDs which I need to download if I have the commit
 729        object 'bar', but not 'foo'".
 730
 731--objects-edge::
 732
 733        Similar to '--objects', but also print the IDs of excluded
 734        commits prefixed with a "-" character.  This is used by
 735        linkgit:git-pack-objects[1] to build "thin" pack, which records
 736        objects in deltified form based on objects contained in these
 737        excluded commits to reduce network traffic.
 738
 739--unpacked::
 740
 741        Only useful with '--objects'; print the object IDs that are not
 742        in packs.
 743
 744--no-walk::
 745
 746        Only show the given revs, but do not traverse their ancestors.
 747
 748--do-walk::
 749
 750        Overrides a previous --no-walk.