From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH] ref-filter: fix stale parsed objects
Date: Tue, 04 Nov 2025 10:31:14 -0800 [thread overview]
Message-ID: <xmqqpl9xps3x.fsf@gitster.g> (raw)
In-Reply-To: <20251104-b4-pks-ref-filter-fixup-v1-1-2fbca52d76d9@pks.im> (Patrick Steinhardt's message of "Tue, 04 Nov 2025 15:36:13 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> In 054f5f457e (ref-filter: parse objects on demand, 2025-10-23) we have
> started to skip parsing some objects in case we don't need to access
> their values in the first place. This was done by introducing a new
> member `struct expand_data::maybe_object` that gets populated on demand
> via `get_or_parse_object()`.
>
> This has led to a regression though where the object now gets reused
> because we don't reset it properly. The `oi` structure is declared in
> global scope, and there is no single place where we reset it before
> invoking `get_object()`. The consequence is that the `maybe_object`
> member doesn't get reset across calls, so subsequent calls will end up
> reusing the same object.
>
> This is only an issue for a subset of retrieved values, as not all of
> the infrastructure ends up calling `get_or_parse_object()`. So the
> effect is limited, which is probably why the issue wasn't detected
> earlier.
>
> Fix the issue by resetting `maybe_object` in `get_object()`.
>
> Reported-by: Junio C Hamano <gitster@pobox.com>
> Based-on-patch-by: Jeff King <peff@peff.net>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> As reported by Junio in <xmqqo6pjt2wn.fsf@gitster.g>. This applies
> directly on top of ps/ref-peeled-tags at 054f5f457e (ref-filter: parse
> objects on demand, 2025-10-23)
>
> Thanks!
Thanks. As we stop reusing a stale maybe_object and instead start
parsing the right object when we need to, I wondered if the "on
demand" commit needs a new benchmark, but the example cited in the
message used %(raw) so it would not be affected, I guess.
Queued. Thanks.
next prev parent reply other threads:[~2025-11-04 18:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 14:36 [PATCH] ref-filter: fix stale parsed objects Patrick Steinhardt
2025-11-04 15:26 ` Junio C Hamano
2025-11-04 18:31 ` Junio C Hamano [this message]
2025-11-04 21:11 ` Jeff King
2025-11-04 22:04 ` Jeff King
2025-11-06 6:04 ` Patrick Steinhardt
2025-11-04 21:33 ` Jeff King
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=xmqqpl9xps3x.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--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.