Re: [PATCH v4 4/5] MyFirstObjectWalk: fix description for counting omitted objects
From: Junio C Hamano <hidden>
Date: 2024-03-26 17:01:03
Dirk Gouders [off-list ref] writes:
quoted hunk
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.