Dirk Gouders <dirk@xxxxxxxxxxx> writes: > diff --git a/Documentation/MyFirstObjectWalk.txt b/Documentation/MyFirstObjectWalk.txt > index a06c712e46..6901561263 100644 > --- a/Documentation/MyFirstObjectWalk.txt > +++ b/Documentation/MyFirstObjectWalk.txt > @@ -754,10 +754,12 @@ points to the same tree object as its grandparent.) > === Counting Omitted Objects > > We also have the capability to enumerate all objects which were omitted by a > -filter, like with `git log --filter=<spec> --filter-print-omitted`. Asking > -`traverse_commit_list_filtered()` to populate the `omitted` list means that our > -object walk does not perform any better than an unfiltered object walk; all > -reachable objects are walked in order to populate the list. > +filter, like with `git log --filter=<spec> --filter-print-omitted`. To do this, > +change `traverse_commit_list()` to `traverse_commit_list_filtered()`, which is > +able to populate an `omitted` list. This list of filtered objects may have > +performance implications, however, because despite filtering objects, the possibly > +much larger set of all reachable objects must be processed in order to > +populate that list. It may be just me not reading what is obvious to everybody else clearly, in which case I am happy to take the above text as-is, but the updated text that says a "list" may have "performance implications" reads a bit odd. It would be understandable if you said "asking for list of filtered objects may have", though. Are you contrasting a call to traverse_commit_list() and traverse_commit_list_filtered() and discussing their relative performance? Of are you contrasting a call to traverse_commit_list_filtered() with and without the omitted parameter, and saying that a call with omitted parameter asks the machinery to do more work so it has to cost more? Other than that I had no trouble with this latest round. Thanks.
