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@xxxxxxxxx/ Thanks, Taylor
