ZheNing Hu <adlternative@xxxxxxxxx> writes: > all blobs, and then use `git cat-file --batch` to retrieve them. This > is not very elegant, or in other words, it might be better to have an > internal implementation of filtering within `git cat-file > --batch-all-objects`. It does sound prominently elegant to have each tool does one task and does it well, and being able to flexibly combine them to achieve a larger task. Once that approach is working well, it may still make sense to give a special case codepath that bundles a specific combination of these primitive features, if use cases for the specific combination appear often. But I do not know if the particular one, "we do not want to feed specific list of objects to check to 'cat-file --batch'", qualifies as one. > For example, `--type-filter`? Is the object type the only thing that people often would want to base their filtering decision on? Will we then see somebody else request a "--size-filter", and then somebody else realizes that the filtering criteria based on size need to be different between blobs (most likely counted in bytes) and trees (it may be more convenient to count the tree entries, not byes)? It sounds rather messy and we may be better off having such an extensible logic in one place. Like rev-list's object list filtering, that is. Is the logic that implements rev-list's object list filtering something that is easily called from the side, as if it were a library routine? Refactoring that and teaching cat-file an option to activate that logic might be more palatable. Thanks.
