From: Taylor Blau <me@ttaylorr.com>
To: ZheNing Hu <adlternative@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git List <git@vger.kernel.org>,
johncai86@gmail.com
Subject: Re: [Question] Can git cat-file have a type filtering option?
Date: Sat, 8 Apr 2023 21:28:28 -0400 [thread overview]
Message-ID: <ZDIUvK/bF7BFqX5q@nand.local> (raw)
In-Reply-To: <CAOLTT8SXXKG3uEd8Q=uh3zx7XeUDUWezGgNUSCd1Fpq-Kyy-2A@mail.gmail.com>
On Sat, Apr 08, 2023 at 02:27:53PM +0800, ZheNing Hu wrote:
> Okay, you're right. It's not "ungraceful" to have each task do its own thing.
> I should clarify that for a command like `git cat-file --batch-all-objects`,
> which traverses all objects, it would be better to have a filter. It might be
> more performant than using `git rev-list --filter | git cat-file --batch`?
Perhaps slightly so, since there is naturally going to be some
duplicated effort spawning processes, loading any shared libraries,
initializing the repository and reading its configuration, etc.
But I'd wager that these are all a negligible cost when compared to the
time we'll have to spend reading, inflating, and printing out all of the
objects in your repository.
Hopefully any task(s) where that cost *wouldn't* be negligible relative
to the rest of the job would be small enough that they could fit into a
single process.
> I don't think so. While `git rev-list` traverses objects and performs
> filtering within a revision, `git cat-file --batch-all-objects` traverses
> all loose and packed objects. It might be difficult to perfectly
> extract the filtering from `git rev-list` and apply it to `git cat-file`.
`rev-list`'s `--all` option does exactly the former: it looks at all
loose and packed objects instead of doing a traditional object walk.
Thanks,
Taylor
next prev parent reply other threads:[~2023-04-09 1:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 14:24 [Question] Can git cat-file have a type filtering option? ZheNing Hu
2023-04-07 16:30 ` Junio C Hamano
2023-04-08 6:27 ` ZheNing Hu
2023-04-09 1:28 ` Taylor Blau [this message]
2023-04-09 2:19 ` Taylor Blau
2023-04-09 2:26 ` Taylor Blau
2023-04-09 6:51 ` ZheNing Hu
2023-04-10 20:01 ` Jeff King
2023-04-10 23:20 ` Taylor Blau
2023-04-09 6:47 ` ZheNing Hu
2023-04-10 20:14 ` Jeff King
2023-04-11 14:09 ` ZheNing Hu
2023-04-12 7:43 ` Jeff King
2023-04-12 9:57 ` ZheNing Hu
2023-04-14 7:30 ` Jeff King
2023-04-14 12:17 ` ZheNing Hu
2023-04-14 15:58 ` Junio C Hamano
2023-04-16 11:15 ` ZheNing Hu
2023-04-14 17:04 ` Linus Torvalds
2023-04-16 12:06 ` Felipe Contreras
2023-04-16 12:43 ` ZheNing Hu
2023-04-09 1:26 ` Taylor Blau
2023-04-09 1:23 ` Taylor Blau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZDIUvK/bF7BFqX5q@nand.local \
--to=me@ttaylorr.com \
--cc=adlternative@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johncai86@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).