From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] builtin/repack: fix `--keep-unreachable` when there are no packs
Date: Tue, 04 Feb 2025 05:28:09 -0800 [thread overview]
Message-ID: <xmqq8qqlx2ja.fsf@gitster.g> (raw)
In-Reply-To: <20250203-b4-pks-repack-unreachable-objects-wo-packfiles-v1-2-7c4d69c5072c@pks.im> (Patrick Steinhardt's message of "Mon, 03 Feb 2025 14:06:55 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> The "--keep-unreachable" flag is supposed to append any unreachable
> objects to the newly written pack. This flag is explicitly documented as
> appending both packed and loose unreachable objects to the new packfile.
> And while this works alright when repacking with preexisting packfiles,
> it stops working when the repository does not have any packfiles at all.
Chuckle. That's a cute corner case the developers never considered,
it seems ;-).
> The root cause are the conditions used to decide whether or not we want
> to append "--pack-loose-unreachable" to git-pack-objects(1). There are
> a couple of conditions here:
>
> - `has_existing_non_kept_packs()` checks whether there are existing
> packfiles. This condition makes sense to guard "--keep-pack=",
> "--unpack-unreachable" and "--keep-unreachable", because all of
> these flags only make sense in combination with existing packfiles.
> But it does not make sense to disable `--pack-loose-unreachable`
> when there aren't any preexisting packfiles, as loose objects can be
> packed into the new packfile regardless of that.
>
> - `delete_redundant` checks whether we want to delete any objects or
> packs that are about to become redundant. The documentation of
> `--keep-unreachable` explicitly says that `git repack -ad` needs to
> be executed for the flag to have an effect.
>
> It is not immediately obvious why such redundant objects need to be
> deleted in order for "--pack-unreachable-objects" to be effective.
> But as things are working as documented this is nothing we'll change
> for now.
>
> - `pack_everything & PACK_CRUFT` checks that we're not creating a
> cruft pack. This condition makes sense in the context of
> "--pack-loose-unreachable", as unreachable objects would end up in
> the cruft pack anyway.
>
> So while the second and third condition are sensible, it does not make
> any sense to condition `--pack-loose-unreachable` on the existence of
> packfiles.
>
> Fix the bug by splitting out the "--pack-loose-unreachable" and only
> making it depend on the second and third condition. Like this, loose
> unreachable objects will be packed regardless of any preexisting
> packfiles.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> builtin/repack.c | 5 ++++-
> t/t7700-repack.sh | 2 +-
> 2 files changed, 5 insertions(+), 2 deletions(-)
Nicely analized and described. Thanks.
next prev parent reply other threads:[~2025-02-04 13:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 13:06 [PATCH 0/2] builtin/repack: fix `--keep-unreachable` when there are no packs Patrick Steinhardt
2025-02-03 13:06 ` [PATCH 1/2] t7700: add tests for `--keep-unreachable` Patrick Steinhardt
2025-02-03 17:13 ` Junio C Hamano
2025-02-03 18:32 ` Jeff King
2025-02-03 23:53 ` Junio C Hamano
2025-02-04 2:35 ` Jeff King
2025-02-04 7:00 ` Patrick Steinhardt
2025-02-03 13:06 ` [PATCH 2/2] builtin/repack: fix `--keep-unreachable` when there are no packs Patrick Steinhardt
2025-02-04 3:01 ` Jeff King
2025-02-04 7:01 ` Patrick Steinhardt
2025-02-04 14:58 ` Jeff King
2025-02-04 13:28 ` Junio C Hamano [this message]
2025-02-04 7:00 ` [PATCH v2] " Patrick Steinhardt
2025-02-04 15:22 ` Jeff King
2025-02-05 5:36 ` Patrick Steinhardt
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=xmqq8qqlx2ja.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.