Re: [RFC v3] cat-file: add a --stdin-cmd mode

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