Re: [Question] Can git cat-file have a type filtering option?
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Apr 9, 2023, 01:26 UTC
- Message-ID
- <ZDIUKqPatP+FX8dM@nand.local>
- In-Reply-To
- <xmqqy1n3k63p.fsf@gitster.g>
On Fri, Apr 07, 2023 at 09:30:18AM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> ZheNing Hu <adlternative@gmail.com> 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.
Show 9 quoted lines
> 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