From: Taylor Blau <me@ttaylorr.com>
To: John Cai <johncai86@gmail.com>
Cc: "Taylor Blau" <me@ttaylorr.com>,
"Christian Couder" <christian.couder@gmail.com>,
git <git@vger.kernel.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Phillip Wood" <phillip.wood123@gmail.com>,
"Eric Wong" <e@80x24.org>
Subject: Re: [RFC v3] cat-file: add a --stdin-cmd mode
Date: Tue, 1 Feb 2022 20:45:27 -0500 [thread overview]
Message-ID: <YfniNw/PoBeei+33@nand.local> (raw)
In-Reply-To: <3FE1D509-8AD0-4F0E-9298-DFD3552A98EF@gmail.com>
On Tue, Feb 01, 2022 at 08:34:06PM -0500, John Cai wrote:
> > So maybe a signal isn't the way to go. But I don't think `--stdin-cmd`
> > is the simplest approach either. At the very least, I don't totally
> > understand your plan after implementing a flush command. You mention
> > that it would be nice to implement other commands, but I'm not totally
> > convinced by your examples[1].
>
> I agree that if flush were the only use case for a new flag, it might not
> be worth it. But, the flush command is only one of the use cases that a
> --stdin-cmd (now changed to --batch-command per Phillip's suggestion)
>
> There are two other commands in this RFC
>
> object <rev>
> info <rev>
>
> These are described in [1] that are also a motivation for a command
> interface.
> The description in [1] explains why a command interface would be necessary.
This seems like a more realistic and well-motivated proposal, IMHO. I am
a little curious that having the ability to switch between asking for an
object's contents and its metadata would lead to saving thousands of
processes per server.
(Apropos of this series, I am curious: how long does GitLab keep a pair
of cat-file programs running for each repository?)
In any case, I'll take a closer look over the aforementioned version and
let you know what my thoughts are, probably tomorrow.
> 1. https://lore.kernel.org/git/20220128183319.43496-1-johncai86@gmail.com/
Thanks,
Taylor
next prev parent reply other threads:[~2022-02-02 1:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 18:33 [RFC v3] cat-file: add a --stdin-cmd mode John Cai
2022-01-31 11:44 ` Bagas Sanjaya
2022-01-31 18:24 ` Junio C Hamano
2022-02-01 9:48 ` Ævar Arnfjörð Bjarmason
2022-02-01 9:39 ` Christian Couder
2022-02-01 17:52 ` Taylor Blau
2022-02-01 19:27 ` John Cai
2022-02-01 20:14 ` Taylor Blau
[not found] ` <3FE1D509-8AD0-4F0E-9298-DFD3552A98EF@gmail.com>
2022-02-02 1:45 ` Taylor Blau [this message]
2022-02-02 13:11 ` John Cai
2022-02-01 10:43 ` Phillip Wood
2022-02-02 15:05 ` John Cai
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfniNw/PoBeei+33@nand.local \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=christian.couder@gmail.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=johncai86@gmail.com \
--cc=phillip.wood123@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).