Re: [PATCH v2 0/8] repack: refactor pack snapshot-ing logic
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Sep 15, 2023, 10:09 UTC
- Message-ID
- <CAP8UFD3nPeF1Dy+cbPAYTFS7AdZJFdGs8qnE5gESU5CQ9h2eng@mail.gmail.com>
- In-Reply-To
- <cover.1694632644.git.me@ttaylorr.com>
On Wed, Sep 13, 2023 at 9:17 PM Taylor Blau <me@ttaylorr.com> wrote:
Show 20 quoted lines
> > Here is a small reroll of my series to clean up some of the internals of > 'git repack' used to track the set of existing packs. > > Much is unchanged from the last round, save for some additional clean-up > on how we handle the '->util' field for each pack's string_list_item in > response to very helpful review from those CC'd. > > As usual, a range-diff is available below for convenience. Thanks in > advance for your review! > > Taylor Blau (8): > builtin/repack.c: extract structure to store existing packs > builtin/repack.c: extract marking packs for deletion > builtin/repack.c: extract redundant pack cleanup for --geometric > builtin/repack.c: extract redundant pack cleanup for existing packs > builtin/repack.c: extract `has_existing_non_kept_packs()` > builtin/repack.c: store existing cruft packs separately > builtin/repack.c: avoid directly inspecting "util" > builtin/repack.c: extract common cruft pack loop
I think it would be a bit nicer with s/builtin\/repack.c/repack/ in all the above commit subjects, but I don't think it's worth a reroll.
Except for another very small nit in a commit message also not worth a reroll, this LGTM.
Thanks, Christian.