On Wed, Feb 26, 2025 at 04:20:55PM +0100, Toon Claes wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > In batch mode, git-cat-file(1) enumerates all objects and prints them > > by iterating through both loose and packed objects. This works without > > considering their reachability at all, and consequently most options to > > filter objects as they exist in e.g. git-rev-list(1) are not applicable. > > In some situations it may still be useful though to filter objects based > > on properties that are inherent to them. This includes the object size > > as well as its type. > > > > Such a filter already exists in git-rev-list(1) with the `--filter=` > > command line option. While this option supports a couple of filters that > > are not applicable to our usecase, some of them are quite a neat fit. > > > > Wire up the filter as an option for git-cat-file(1). This allows us to > > reuse the same syntax as in git-rev-list(1) so that we don't have to > > reinvent the wheel. For now, we die when any of the filter options has > > been passed by the user, but they will be wired up in subsequent > > commits. > > > > Note that we don't use the same `--filter=` name fo the option as we use > > in git-rev-list(1). We already have `--filters`, and having both > > `--filter=` and `--filters` would be quite confusing. Instead, the new > > option is called `--objects-filter`. > > I'm not sure I agree. I would rather have consistency in various > commands. Because `--filters` doesn't accept an argument, so I would say > having both `--filters` and `--filter=` is fine. I see in various places > we already use `OPT_PARSE_LIST_OBJECTS_FILTER` which defines the option > as `--filter=`, so it's pretty standard for several commands. I'd > prefer git-cat-file(1) to follow that as well. But that's my 2 cents. I'll wait for a third party to chime in as a tie breaker here :) I'm not feeling overly strong about it, but still think that it's just too easy to get wrong when those options are so extremely similarly named. Patrick
