On 19 Jan 2022, at 14:38, Taylor Blau wrote: > On Wed, Jan 19, 2022 at 05:58:40PM +0000, John Cai via GitGitGadget wrote: >> I think this will be useful for other things, e.g. a not-trivial part of >> "cat-file --batch" time is spent on parsing its argument and seeing if it's >> a revision, ref etc. >> >> So we could e.g. add a command that only accepts a full-length 40 character >> SHA-1, or switch the --format output mid-request etc. > > I would like to see a more concrete proposal or need for this sort of > thing before we go too far down adding a new mode to a command so > fundamental as cat-file is. Thanks for the feedback! I realized I should have made this an RFC first. I’ll submit an RFC separately. > > Between your two proposals for other commands that you could add, I am > not convinced that either of them needs to be in cat-file itself. IOW, > you could easily inject another process in between which verifies that > the provided objects are 40 character SHA-1s. > > The latter, changing the output format in-process, seems dubious to me. > Is the start-up time of cat-file so slow (and you need to change formats > so often) that the two together are unbearable? I'd be surprised if they > were (and if so, we should focus our efforts on improving Git's start-up > time). > > In the meantime, this is quite an invasive way to provide callers a way > to control the output stream. If there really is a need to just force > cat-file to flush more often, perhaps consider designating a special > signal that we could treat as a request to flush the output stream? > > Thanks, > Taylor
