From: Taylor Blau <me@ttaylorr.com>
To: Elijah Newren <newren@gmail.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 5/5] repack: begin combining cruft packs with `--combine-cruft-below-size`
Date: Wed, 19 Mar 2025 18:50:15 -0400 [thread overview]
Message-ID: <Z9tKJ47+3ffiB2fx@nand.local> (raw)
In-Reply-To: <CABPp-BFhZ1JGR_qWSgmcZm=Pix2n6z1AQ+-R-mw9Q_fWFi=_Ew@mail.gmail.com>
On Wed, Mar 19, 2025 at 07:21:01AM -0700, Elijah Newren wrote:
> On Mon, Mar 17, 2025 at 4:00 PM Taylor Blau <me@ttaylorr.com> wrote:
> >
> > The previous commit changed the behavior of repack's '--max-cruft-size'
> > to specify a cruft pack-specific override for '--max-pack-size'.
> >
> > Introduce a new flag, '--combine-cruft-below-size' which is a
> > replacement for the old behavior of '--max-cruft-size'. This new flag
> > does explicitly what it says: it combines together cruft packs which are
> > smaller than a given threshold, and prohibits repacking ones which are
> > larger.
>
> To me "prohibits" suggests some kind of stronger action that
> potentially persists beyond the end of this operation. Perhaps this
> could be reworded to something like
> s/prohibits repacking ones/leaves alone packs/ ?
Fair enough, I went with "leaves alone ones which are larger".
> > This accomplishes the original intent of '--max-cruft-size', which was
> > to avoid repacking cruft packs larger than the given threshold.
> >
> > The new behavior is slightly different. Instead of building up small
> > packs together until the threshold is met, '--combine-cruft-below-size'
> > packs up *all* cruft packs smaller than the threshold. This means that
> > we may make a pack much larger than the given threshold (e.g., if you
> > aggregate 5 packs which are each 99 MiB in size with a threshold of 100
> > MiB).
> >
> > But that's OK: the point isn't to restrict the size of the cruft packs
> > we generate, it's to avoid working with ones that have already grown too
> > large. If repositories still want to limit the size of the generated
> > cruft pack(s), they may use '--max-cruft-size' instead.
>
> ...but then they wouldn't get any cruft packs being combined. Did you
> mean s/instead/together with --combine-cruft-below-size/ ?
Oops, yeah; I meant to imply that '--max-cruft-size' was/is still an
option, not that one excludes the other. I went for s/instead//.
> > There's some minor test fallout as a result of the slight differences in
> > behavior between the old meaning of '--max-cruft-size' and the behavior
> > of '--combine-cruft-below-size'. In the test which is now called
> > "--combine-cruft-below-size combines packs", we need to use the new flag
> > over the old one to exercise that test's intended behavior. The
> > remainder of the changes there are to improve the clarity of the
> > comments.
> >
> > Suggested-by: Elijah Newren <newren@gmail.com>
> > Signed-off-by: Taylor Blau <me@ttaylorr.com>
> > ---
> > Documentation/git-repack.adoc | 8 ++++++++
> > builtin/repack.c | 38 +++++++++++++++++++++++------------
> > t/t7704-repack-cruft.sh | 22 +++++++++++---------
> > 3 files changed, 46 insertions(+), 22 deletions(-)
> >
> > diff --git a/Documentation/git-repack.adoc b/Documentation/git-repack.adoc
> > index 11db43b1c5..8e6d61aa2f 100644
> > --- a/Documentation/git-repack.adoc
> > +++ b/Documentation/git-repack.adoc
> > @@ -81,6 +81,14 @@ to the new separate pack will be written.
> > `--max-pack-size` (if any) by default. See the documentation for
> > `--max-pack-size` for more details.
> >
> > +--combine-cruft-below-size=<n>::
> > + When generating cruft packs without pruning, only repack
> > + existing cruft packs whose size is strictly less than `<n>`.
> > + Cruft packs whose size is greater than or equal to `<n>` are
> > + left as-is and not repacked. Useful when you want to avoid
> > + repacking large cruft pack(s) in repositories that have many
> > + and/or large unreachable objects.
> > +
>
> Does it make sense to modify the documentation for either the
> --max-cruft-szie or --combine-cruft-below-size options to suggest that
> if both are used, it is recommended to make --max-cruft-size twice (or
> more) the value of --combine-cruft-below-size ?
Ehhh... I kind of want to avoid mentioning it TBH. Part of the reason
there is that I think the explanation of "why" is a little too detailed
to spell out meaningfully in the documentation while still keeping it
concise. But more importantly I want to avoid encouraging people to use
the '--max-{pack,cruft}-size' flags to begin with, since there really is
no reason to use them outside of filesystem constraints.
Thanks,
Taylor
next prev parent reply other threads:[~2025-03-19 22:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 23:00 [PATCH 0/5] repack: introduce '--combine-cruft-below-size' Taylor Blau
2025-03-17 23:00 ` [PATCH 1/5] t/t5329-pack-objects-cruft.sh: evict 'repack'-related tests Taylor Blau
2025-03-19 14:20 ` Elijah Newren
2025-03-17 23:00 ` [PATCH 2/5] t/t7704-repack-cruft.sh: clarify wording in --max-cruft-size tests Taylor Blau
2025-03-19 14:20 ` Elijah Newren
2025-03-17 23:00 ` [PATCH 3/5] t/t7704-repack-cruft.sh: consolidate `write_blob()` Taylor Blau
2025-03-17 23:00 ` [PATCH 4/5] repack: avoid combining cruft packs with `--max-cruft-size` Taylor Blau
2025-03-17 23:00 ` [PATCH 5/5] repack: begin combining cruft packs with `--combine-cruft-below-size` Taylor Blau
2025-03-18 16:30 ` Junio C Hamano
2025-03-19 22:40 ` Taylor Blau
2025-03-19 14:21 ` Elijah Newren
2025-03-19 22:50 ` Taylor Blau [this message]
2025-03-19 22:52 ` [PATCH v2 0/5] repack: introduce '--combine-cruft-below-size' Taylor Blau
2025-03-19 22:52 ` [PATCH v2 1/5] t/t5329-pack-objects-cruft.sh: evict 'repack'-related tests Taylor Blau
2025-03-19 22:52 ` [PATCH v2 2/5] t/t7704-repack-cruft.sh: clarify wording in --max-cruft-size tests Taylor Blau
2025-03-19 22:52 ` [PATCH v2 3/5] t/t7704-repack-cruft.sh: consolidate `write_blob()` Taylor Blau
2025-03-19 22:52 ` [PATCH v2 4/5] repack: avoid combining cruft packs with `--max-cruft-size` Taylor Blau
2025-03-19 22:52 ` [PATCH v2 5/5] repack: begin combining cruft packs with `--combine-cruft-below-size` Taylor Blau
2025-03-20 4:30 ` [PATCH v2 0/5] repack: introduce '--combine-cruft-below-size' Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9tKJ47+3ffiB2fx@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).