On Thu, Jun 15, 2023 at 03:50:17PM -0700, Junio C Hamano wrote: > Christian Couder <christian.couder@xxxxxxxxx> writes: > > > When using the `--filter=<filter-spec>` option, `git pack-objects` will > > omit some objects from the resulting packfile(s) it produces. It could > > be useful to know about these omitted objects though. > > > > For example, we might want to write these objects into a separate > > packfile by piping them into another `git pack-object` process. > > Or we might want to check if these objects are available from a > > promisor remote. > > > > Anyway, this patch implements a simple way to let us know about these > > objects by simply printing their oid, one per line, on stdout when the > > new `--print-filtered` flag is passed. > > Makes sense. It is a bit sad that we have to accumulate everything > until the end at which time we have to dump the accumulated in bulk, > but that is a current limitation of list-objects-filter API and not > within the scope of this change. We may in the longer term want to > see if we can make the collection of filtered-out objects streamable > by replacing the .omits object array with a callback function, or do > something along that line. Hmm. I think it is possible to use something like `git pack-objects`'s `--stdin-packs` mode to accomplish this without needing to keep track of the set of discarded objects (i.e. those which don't match the filter). IIUC, the set of objects which don't match the filter is the same as the set of all objects in packs beforehand, differenced with the set of objects that shows up in the pack containing objects which *do* match the filter. If you mark all of the "before" packs with `-` in the input to `--stdin-packs`, and then pass along the pack containing the filtered set without `-` (to indicate that the resulting pack should not contain any objects which appear in that pack), I think you would end up with the set of non-matching objects. Thanks, Taylor