On Mon, Oct 09, 2023 at 11:09:07AM -0700, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> writes: > > > On Sat, Oct 07, 2023 at 01:20:02AM -0700, Junio C Hamano wrote: > >> * tb/repack-max-cruft-size (2023-10-05) 4 commits > >> (merged to 'next' on 2023-10-06 at b3ca6df3b9) > >> + builtin/repack.c: avoid making cruft packs preferred > >> + builtin/repack.c: implement support for `--max-cruft-size` > >> + builtin/repack.c: parse `--max-pack-size` with OPT_MAGNITUDE > >> + t7700: split cruft-related tests to t7704 > >> > >> "git repack" learned "--max-cruft-size" to prevent cruft packs from > >> growing without bounds. > >> > >> Will merge to 'master'. > >> source: <cover.1696293862.git.me@xxxxxxxxxxxx> > >> source: <035393935108d02aaf8927189b05102f4f74f340.1696370003.git.me@xxxxxxxxxxxx> > > > > Thanks. On a semi-related note, did you want to pick up my patch in > > > > https://lore.kernel.org/git/035393935108d02aaf8927189b05102f4f74f340.1696370003.git.me@xxxxxxxxxxxx/ > > > > ? That should address a performance bug that occurs when a repository > > (incorrectly) chooses a cruft pack as its preferred pack source when > > writing a MIDX bitmap, significantly impeding the pack-reuse mechanism. > > Isn't that in the above list already as b3ca6df3b9^2? Oops, duh. I hadn't expected you to group that patch in with the rest of tb/repack-max-cruft-size. I'll put on my glasses the next time before suggesting you dropped one of my patches on the floor... ;-) Thanks, Taylor
