On Fri, Apr 07, 2023 at 09:30:18AM -0700, Junio C Hamano wrote: > 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. Yeah, agreed. It may be *convenient* to have an easy-to-reach option in cat-file like '--exclude-type=tree,commit,tag' or something. But the argument falls on a pretty slippery slope, as I think you note below. > 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. Yes, exactly. This definitely feels like a "do one thing and do it well". `rev-list` is the tool we have for listing revisions and objects, and it can produce output that is compatible with the kind of input that other tools (like `cat-file`) can interpret. Thanks, Taylor
