From: Justin Tobler <jltobler@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Wolfgang Kritzinger <wkritzinger@atlassian.com>
Subject: Re: [PATCH 3/5] odb/source-files: make the second read an implementation detail
Date: Wed, 14 Oct 2026 10:37:37 -0500 [thread overview]
Message-ID: <as-g2QdXl2zJkNoO@denethor> (raw)
In-Reply-To: <as8ne87RmBCl10ng@pks.im>
On 26/10/14 08:55AM, Patrick Steinhardt wrote:
> On Tue, Oct 13, 2026 at 04:28:37PM -0500, Justin Tobler wrote:
> > On 26/10/13 09:36AM, Patrick Steinhardt wrote:
> > > Note that the "packed" source also used this flag to figure out whether
> > > it should try to surface an object via a packfile that should have the
> > > object as determined by a multi-pack index, but where the packfile has
> > > vanished. The multi-pack index is stale in that case, and that scenario
> > > should really only happen when the process is racing with a concurrent
> > > maintenance task.
> > >
> > > This code is adapted to instead use `OBJECT_INFO_QUICK`, which means
> > > that the fallback may trigger on the first read already, but not in a
> > > case where callers know to handle false negatives already. In the worst
> > > case this could cause another scan through all packfiles covered by the
> > > multi-pack index. But that scan should be fast enough anyway, and it
> > > only triggers when we hit the race. So the effect thereof should be
> > > limited.
> >
> > Would it be more correct to say that we are now using the absence of the
> > OBJECT_INFO_QUICK flag trigger the fallback?
>
> I dunno. Whether we check for absence or presence, in either case we use
> the flag. So I'm inclined to leave this as-is as it starts to read a bit
> awkward otherwise.
>
> Let me know in case you feel strongly though.
I don't feel too strongly either way. When I read it the first time, my
first thought was that we were using the OBJECT_INFO_QUICK flag to mean
the same thing as OBJECT_INFO_SECOND_READ which confused me. Then I
realized it was in fact the exact opposite.
> > > diff --git a/odb/source-files.c b/odb/source-files.c
> > > index 54235821d5..9788a5adf4 100644
> > > --- a/odb/source-files.c
> > > +++ b/odb/source-files.c
> > > @@ -444,6 +449,9 @@ static enum odb_read_status odb_source_files_read_object_info(struct odb_source
> > > }
> > >
> > > for (struct odb_files_dir *dir = files->dirs; dir; dir = dir->next) {
> > > + if (retry)
> > > + break;
> >
> > IIUC, we don't need to bother checking the loose objects a second time
> > so we exit the look early.
> >
> > Nit: Mostly just a style preference, but instead of entering the loop
> > just to break out early for retries, could we just return early prior
> > the loop starting? It looks like the rest of the function is skipped on
> > the second read anyways.
>
> Yes. But I've got a follow-up patch series that has some fixes for how
> we reload alternates, and as part of that I'll start to iterate over
> loose object directories that have been added after re-reading
> ".git/objects/info/alternates". So this is a bit awkward right now, but
> makes the follow-up series a bit easier.
Ok, this sounds reasonable to me.
-Justin
next prev parent reply other threads:[~2026-10-14 15:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 7:36 [PATCH 0/5] odb/files: cleanups and improvements for alternates Patrick Steinhardt
2026-10-13 7:36 ` [PATCH 1/5] odb/source-files: fix performance when reading objects with alternates Patrick Steinhardt
2026-10-13 20:46 ` Justin Tobler
2026-10-13 7:36 ` [PATCH 2/5] odb/source-files: fix performance when streaming " Patrick Steinhardt
2026-10-13 20:51 ` Justin Tobler
2026-10-13 7:36 ` [PATCH 3/5] odb/source-files: make the second read an implementation detail Patrick Steinhardt
2026-10-13 21:28 ` Justin Tobler
2026-10-14 6:55 ` Patrick Steinhardt
2026-10-14 15:37 ` Justin Tobler [this message]
2026-10-13 7:36 ` [PATCH 4/5] odb: remove read loop for found objects Patrick Steinhardt
2026-10-13 21:48 ` Justin Tobler
2026-10-14 6:56 ` Patrick Steinhardt
2026-10-14 15:38 ` Justin Tobler
2026-10-13 7:36 ` [PATCH 5/5] odb/source: drop `local` flag Patrick Steinhardt
2026-10-13 22:44 ` Justin Tobler
2026-10-14 6:56 ` Patrick Steinhardt
2026-10-14 15:43 ` Justin Tobler
2026-10-14 8:53 ` [PATCH v2 0/6] odb/files: cleanups and improvements for alternates Patrick Steinhardt
2026-10-14 8:53 ` [PATCH v2 1/6] odb/source-files: fix performance when reading objects with alternates Patrick Steinhardt
2026-10-14 13:35 ` Johannes Schindelin
2026-10-14 13:44 ` Patrick Steinhardt
2026-10-14 8:53 ` [PATCH v2 2/6] odb/source-files: fix performance when streaming " Patrick Steinhardt
2026-10-14 8:53 ` [PATCH v2 3/6] odb/source-files: make the second read an implementation detail Patrick Steinhardt
2026-10-14 8:53 ` [PATCH v2 4/6] odb: remove read loop for found objects Patrick Steinhardt
2026-10-14 8:53 ` [PATCH v2 5/6] odb: don't try re-fetching corrupt objects Patrick Steinhardt
2026-10-14 15:59 ` Justin Tobler
2026-10-14 8:53 ` [PATCH v2 6/6] odb/source: drop `local` flag 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=as-g2QdXl2zJkNoO@denethor \
--to=jltobler@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=wkritzinger@atlassian.com \
/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