Re: [PATCH 0/2] Fix background maintenance regression in Git 2.45.0

From: Taylor Blau <me@ttaylorr.com>
Date: Jul 19, 2024, 13:38 UTC
Message-ID: <ZppsWZ6u05U65Blp@nand.local>
In-Reply-To: <118b164e-67c5-4dfc-b440-62b8986bf356@gmail.com>

On Fri, Jul 19, 2024 at 09:21:51AM -0400, Derrick Stolee wrote:

Show 12 quoted lines

> On 7/18/24 6:50 PM, Taylor Blau wrote:
>
> > I think this matches my own understanding, but let me know if I'm
> > missing something. Assuming I'm thinking about this the same way you
> > are, the fix (stop using --stdin-packss) makes sense to me.
>
> Your interpretation matches mine. Thanks for the careful read.
>
> I think we can accomplish similar goals that match the reasoning for
> --stdin-packs (better deltas while also limiting the object walk to the
> repacked objects) with some changes to read_object_list_from_stdin(),
> but that's a more subtle kind of change.

FWIW, the main motivation for that change was to limit the amount of cross-process I/O that was necessary to generate the new pack. I figured that for relatively small amounts of packs which contain relatively large amounts of objects that it would be more efficient to write out the pack names than the object names.

I was thinking a little bit about how we would alter the behavior of '--stdin-packs' to match what the 'multi-pack-index repack' caller needs. I agree that it is possible, and I doubly agree that it is subtle ;-).

TBH, I think that the amount of I/O we're potentially saving is dwarfed by the amount of I/O and CPU time it takes to actually generate the new pack, so I doubt the effort to make such a subtle change would be all that worthwhile, though certainly an interesting exercise ;-).

> Taking this change as-is will cause a regression in the quality of
> delta choices, but recovers our ability to expire "repacked" pack-files
> in all cases.

Yeah, definitely.

Thanks, Taylor