From: Jeff King Date: Tue, 14 Jul 2026 21:47:09 GMT Subject: Re: [PATCH 2/2] fetch-pack: accept "pack" output for packfile URIs Message-ID: <20260714214709.GA4095533@coredump.intra.peff.net> In-Reply-To: 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