From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 0/3] cat-file: add %(objectmode) avoid verifying submodules' OIDs
Date: Tue, 12 Mar 2024 12:28:48 -0700 [thread overview]
Message-ID: <xmqq1q8fl05r.fsf@gitster.g> (raw)
In-Reply-To: <20240312085901.GA69635@coredump.intra.peff.net> (Jeff King's message of "Tue, 12 Mar 2024 04:59:01 -0400")
Jeff King <peff@peff.net> writes:
> That is an interesting direction. In practice I guess you might want to
> expand trees (to show their contents) or perhaps commits (to traverse
> history and/or look at their trees). And we already have tools to do
> that.
>
> So for example you can already do:
>
> git ls-tree --format='%(objectname) %(objectmode)' HEAD
>
> Or if you wanted to mix-and-match with other cat-file placeholders, you
> can do:
>
> git ls-tree --format='%(objectname) %(objectmode)' HEAD |
> git cat-file --batch-check='%(objectname) %(deltabase) %(rest)'
>
> That is a little less efficient (we look up the object twice), but once
> you are working with hex object ids it is not too bad (cat-file is
> heavily optimized here). Of course in the long run I think we should
> move to a future where the formatting code is shared, and you can just
> ask ls-tree for deltabase if you want to.
I was imagining more about a use case "cat-file --batch" was
originally designed for---having a long-running single process
and ask any and all questions you have about various objects in the
object database by interacting with it. So "yes, ls-tree can
already give us that information", while it is true, shoots at a
different direction from what I had in mind.
> The strategy so far has been making sure cat-file can efficiently take
> in the output of these other tools to further describe objects. But
> moving towards a unified output formatting model would be even better, I
> think. In the meantime, I think cat-file learning %(objectmode) makes
> sense for single names (rather than listing trees), and fortunately it
> uses the same (obvious) name that ls-tree does, so we won't have a
> problem unifying them later.
Yes, enriching the output format side is an orthogonal issue from
the input side, and the %(objectmode) thing that gives a piece of
information that is additionally available on top of the various
pieces of information about the object itself does make sense.
> The patch itself looked reasonable to me, modulo the comments you
> already made.
>
> -Peff
next prev parent reply other threads:[~2024-03-12 19:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-11 18:55 [PATCH 0/3] cat-file: add %(objectmode) avoid verifying submodules' OIDs Johannes Schindelin via GitGitGadget
2024-03-11 18:56 ` [PATCH 1/3] t1006: update 'run_tests' to test generic object specifiers Victoria Dye via GitGitGadget
2024-03-11 21:54 ` Junio C Hamano
2024-03-11 18:56 ` [PATCH 2/3] cat-file: add %(objectmode) atom Victoria Dye via GitGitGadget
2024-03-11 22:15 ` Junio C Hamano
2024-03-13 21:23 ` Junio C Hamano
2024-03-11 18:56 ` [PATCH 3/3] cat-file: avoid verifying submodules' OIDs Johannes Schindelin via GitGitGadget
2024-03-12 8:58 ` Jeff King
2024-03-12 18:35 ` Junio C Hamano
2024-03-12 22:17 ` Jeff King
2024-03-13 15:22 ` Junio C Hamano
2024-03-11 21:43 ` [PATCH 0/3] cat-file: add %(objectmode) " Junio C Hamano
2024-03-12 8:59 ` Jeff King
2024-03-12 19:28 ` Junio C Hamano [this message]
2024-03-12 22:03 ` Jeff King
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=xmqq1q8fl05r.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.