From: Jonathan Tan <jonathantanmy@google.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Jonathan Tan <jonathantanmy@google.com>,
git@vger.kernel.org, hanyang.tony@bytedance.com
Subject: Re: [PATCH 2/3] index-pack: no blobs during outgoing link check
Date: Tue, 3 Dec 2024 13:40:00 -0800 [thread overview]
Message-ID: <20241203214000.2032992-1-jonathantanmy@google.com> (raw)
In-Reply-To: <Z06ejDgTnC6gWXgx@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> > This situation has not been observed yet - we have only noticed missing
> > commits, not missing trees or blobs. (In fact, if it were believed that
> > only missing commits are problematic, one could argue that we should
> > also exclude trees during the outgoing link check; but it is safer to
> > include them.)
> >
> > Due to the rarity of the situation (it has not been observed to happen
> > in real life), and because the "penalty" in such a situation is merely
> > to refetch the missing blob when it's needed, the tradeoff seems
> > worth it.
>
> So is this a one-off event that may happen once per blob, or would we
> eventually evict the refetched blob and run into the same situation
> repeatedly?
One-off, since when refetched, the blob is in a promisor pack (and
thus won't be GC-ed). I've added this to the code comment that I added
following your suggestion below.
> > diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> > index 8e7d14c17e..58d24540dc 100644
> > --- a/builtin/index-pack.c
> > +++ b/builtin/index-pack.c
> > @@ -830,8 +830,10 @@ static void do_record_outgoing_links(struct object *obj)
> > * verified, so do not print any here.
> > */
> > return;
> > - while (tree_entry_gently(&desc, &entry))
> > - record_outgoing_link(&entry.oid);
> > + while (tree_entry_gently(&desc, &entry)) {
> > + if (S_ISDIR(entry.mode))
> > + record_outgoing_link(&entry.oid);
> > + }
>
> Without the context of the commit message this code snippet likely would
> not make any sense to a reader. The "correct" logic would be to record
> all objects, regardless of whether they are an object ID or not. But we
> explicitly choose not to as a tradeoff between performance and
> correctness.
>
> All to say that we should have a comment here that explains what is
> going on.
>
> Patrick
Makes sense. I had to move almost the entirety of the commit message
into a code comment - I don't think putting merely a part here would be
enough context.
next prev parent reply other threads:[~2024-12-03 21:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 20:18 [PATCH 0/3] Performance improvements for repacking non-promisor objects Jonathan Tan
2024-12-02 20:18 ` [PATCH 1/3] index-pack: dedup first during outgoing link check Jonathan Tan
2024-12-02 21:24 ` Josh Steadmon
2024-12-02 20:18 ` [PATCH 2/3] index-pack: no blobs " Jonathan Tan
2024-12-03 6:00 ` Patrick Steinhardt
2024-12-03 21:40 ` Jonathan Tan [this message]
2024-12-03 22:16 ` Junio C Hamano
2024-12-02 20:18 ` [PATCH 3/3] index-pack: commit tree " Jonathan Tan
2024-12-03 3:10 ` Junio C Hamano
2024-12-03 21:42 ` Jonathan Tan
2024-12-04 0:21 ` Junio C Hamano
2024-12-09 20:29 ` Jonathan Tan
2024-12-09 23:51 ` Junio C Hamano
2024-12-02 21:25 ` [PATCH 0/3] Performance improvements for repacking non-promisor objects Josh Steadmon
2024-12-03 4:09 ` Junio C Hamano
2024-12-03 4:18 ` Junio C Hamano
2024-12-03 4:20 ` Junio C Hamano
2024-12-03 4:39 ` Junio C Hamano
2024-12-03 21:43 ` [PATCH v2 " Jonathan Tan
2024-12-03 21:43 ` [PATCH v2 1/3] index-pack --promisor: dedup before checking links Jonathan Tan
2024-12-03 21:43 ` [PATCH v2 2/3] index-pack --promisor: don't check blobs Jonathan Tan
2024-12-03 21:43 ` [PATCH v2 3/3] index-pack --promisor: also check commits' trees Jonathan Tan
2024-12-03 21:52 ` [PATCH v3 0/3] Performance improvements for repacking non-promisor objects Jonathan Tan
2024-12-03 21:52 ` [PATCH v3 1/3] index-pack --promisor: dedup before checking links Jonathan Tan
2024-12-04 4:36 ` Junio C Hamano
2024-12-03 21:52 ` [PATCH v3 2/3] index-pack --promisor: don't check blobs Jonathan Tan
2024-12-03 21:52 ` [PATCH v3 3/3] index-pack --promisor: also check commits' trees Jonathan Tan
2024-12-04 2:22 ` [PATCH v3 0/3] Performance improvements for repacking non-promisor objects Junio C Hamano
2024-12-04 4:46 ` [PATCH 4/3] index-pack: work around false positive use of uninitialized variable Junio C Hamano
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=20241203214000.2032992-1-jonathantanmy@google.com \
--to=jonathantanmy@google.com \
--cc=git@vger.kernel.org \
--cc=hanyang.tony@bytedance.com \
--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 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).