Re: [PATCH 2/2] fetch-pack: accept "pack" output for packfile URIs

From: Jeff King <peff@peff.net>
Date: Jul 14, 2026, 21:47 UTC
Message-ID: <20260714214709.GA4095533@coredump.intra.peff.net>
In-Reply-To: <alaCQKXKcWr723Ij@com-76773>

On Tue, Jul 14, 2026 at 11:38:56AM -0700, Ted Nyman wrote:

Show 9 quoted lines

> > I also think this would all be much nicer with a strbuf (which would
> > let us get rid of the magic numbers), but that is a slightly larger
> > refactor:
> 
> Using a strbuf makes sense. One wrinkle, I think, is that with
> transfer.fsckobjects enabled, index-pack can emit dangling .gitmodules
> OIDs after the initial pack/keep line, which parse_gitmodules_oids()
> still needs to read from cmd.out. Would strbuf_getwholeline_fd() be a
> better fit here, so we don't consume those with strbuf_read()?

Ah, yeah, I didn't think about whether it might have more output. I _think_ it actually works just fine with more output because the memcmp() is limited to the hash algo's hex_sz. For the same reason what I posted works even though it has the trailing newline.

It is a bit subtle, though. Using getwholeline_fd would work (though you still have the trailing newline subtlety). Or maybe just using strbuf_setlen() to cut off the output (ironically it is probably more efficient to read the whole thing in and then chomp it, since getwholeline_fd will read() one char at a time).

The "cleanest" thing is perhaps xfdopen() followed by strbuf_getline(), but maybe that's overkill.

I'd be happy with any of the solutions. Or even just keeping the magic numbers but maybe with a comment explaining what the heck "6" means.

> I'll also fix the --index-pack-args documentation while rerolling.

Great, thanks.

-Peff