mbox series

[v3,0/1] pack-objects: freshen objects with multi-cruft packs

Message ID cover.1741133712.git.me@ttaylorr.com (mailing list archive)
Headers show
Series pack-objects: freshen objects with multi-cruft packs | expand

Message

Taylor Blau March 5, 2025, 12:15 a.m. UTC
This is a(nother) reroll of my series to fix a bug in freshening objects
with multiple cruft packs.

The only update since last time is that I dropped the first patch, after
Patrick astutely pointed out a flaw with the approach pursued there.
That flaw is why I wrote '--max-cruft-size' in what appeared to be a
convoluted fashion, but I couldn't remember my line of thinking at the
time.

As usual, there is a range-diff showing as much below. Thanks again,
Patrick, for catching what would be a very frustrating issue to deal
with later on ;-).

Taylor Blau (1):
  builtin/pack-objects.c: freshen objects from existing cruft packs

 builtin/pack-objects.c  | 118 ++++++++++++++++++++++++++++++++++------
 packfile.c              |   3 +-
 packfile.h              |   2 +
 t/t7704-repack-cruft.sh |  63 +++++++++++++++++++++
 4 files changed, 168 insertions(+), 18 deletions(-)

Range-diff against v2:
1:  63ea9d4d00e < -:  ----------- builtin/repack.c: simplify cruft pack aggregation
2:  7ba9054701b = 1:  6e93471f9a8 builtin/pack-objects.c: freshen objects from existing cruft packs

base-commit: 08bdfd453584e489d5a551aecbdcb77584e1b958

Comments

Patrick Steinhardt March 6, 2025, 10:31 a.m. UTC | #1
On Tue, Mar 04, 2025 at 07:15:14PM -0500, Taylor Blau wrote:
> This is a(nother) reroll of my series to fix a bug in freshening objects
> with multiple cruft packs.
> 
> The only update since last time is that I dropped the first patch, after
> Patrick astutely pointed out a flaw with the approach pursued there.
> That flaw is why I wrote '--max-cruft-size' in what appeared to be a
> convoluted fashion, but I couldn't remember my line of thinking at the
> time.
> 
> As usual, there is a range-diff showing as much below. Thanks again,
> Patrick, for catching what would be a very frustrating issue to deal
> with later on ;-).

Would it maybe make sense to add a commit that explains _why_ the
existing algorithm looks as it does so that the next person won't be
triggered to remove the code again?

Patrick