]> git.ipfire.org Git - thirdparty/git.git/commit
builtin/pack-objects.c: support `--max-pack-size` with `--cruft`
authorTaylor Blau <me@ttaylorr.com>
Mon, 28 Aug 2023 22:49:07 +0000 (18:49 -0400)
committerJunio C Hamano <gitster@pobox.com>
Tue, 29 Aug 2023 18:58:06 +0000 (11:58 -0700)
commit61568efa95608fdafffe67967a82e88bcd90fade
tree388adbd8914663200d9c680738073a58089f3172
parente741c078721f8232da769a1100433d96c4393b32
builtin/pack-objects.c: support `--max-pack-size` with `--cruft`

When pack-objects learned the `--cruft` option back in b757353676
(builtin/pack-objects.c: --cruft without expiration, 2022-05-20), we
explicitly forbade `--cruft` with `--max-pack-size`.

At the time, there was no specific rationale given in the patch for not
supporting the `--max-pack-size` option with `--cruft`. (As best I can
remember, it's because we were trying to push users towards only ever
having a single cruft pack, but I cannot be sure).

However, `--max-pack-size` is flexible enough that it already works with
`--cruft` and can shard unreachable objects across multiple cruft packs,
creating separate ".mtimes" files as appropriate. In fact, the
`--max-pack-size` option worked with `--cruft` as far back as
b757353676!

This is because we overwrite the `written_list`, and pass down the
appropriate length, i.e. the number of objects written in each pack
shard.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-pack-objects.txt
builtin/pack-objects.c
builtin/repack.c
t/t5329-pack-objects-cruft.sh