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

[Jeff King <peff@peff.net>]

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

> > 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