git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [Question] Can git cat-file have a type filtering option?

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 7, 2023, 16:30 UTC
Message-ID
<xmqqy1n3k63p.fsf@gitster.g>
In-Reply-To
<CAOLTT8RTB7kpabN=Rv1nHvKTaYh6pLR6moOJhfC2wdtUG_xahQ@mail.gmail.com>
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.

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.
Previous: ZheNing HuNext: ZheNing Hu
Message 2 of 23 in “[Question] Can git cat-file have a type filtering option?”
  1. ZheNing HuApr 7, 2023
  2. Junio C HamanoApr 7, 2023
  3. ZheNing HuApr 8, 2023
  4. Taylor BlauApr 9, 2023
  5. Taylor BlauApr 9, 2023
  6. Taylor BlauApr 9, 2023
  7. ZheNing HuApr 9, 2023
  8. Jeff KingApr 10, 2023
  9. Taylor BlauApr 10, 2023
  10. ZheNing HuApr 9, 2023
  11. Jeff KingApr 10, 2023
  12. ZheNing HuApr 11, 2023
  13. Jeff KingApr 12, 2023
  14. ZheNing HuApr 12, 2023
  15. Jeff KingApr 14, 2023
  16. ZheNing HuApr 14, 2023
  17. Junio C HamanoApr 14, 2023
  18. ZheNing HuApr 16, 2023
  19. Linus TorvaldsApr 14, 2023
  20. Felipe ContrerasApr 16, 2023
  21. ZheNing HuApr 16, 2023
  22. Taylor BlauApr 9, 2023
  23. Taylor BlauApr 9, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.