From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 3/5] odb/source: let callers discern missing and corrupt objects
Date: Fri, 21 Aug 2026 07:45:21 +0200 [thread overview]
Message-ID: <aofl8e4P6BqJaQEm@pks.im> (raw)
In-Reply-To: <CAOLa=ZSs-9VU2eKT8DUJ7FzZCAkgRzZ6_XQZBP=x7avxpFp7qw@mail.gmail.com>
On Thu, Aug 20, 2026 at 05:09:51PM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > On Thu, Aug 20, 2026 at 08:56:50AM -0400, Karthik Nayak wrote:
> Oops. Thanks for the detailed response.
>
> I think I made my case in reverse, but my original argument still
> holds.
>
> ret_packed ret_loose ret_packed != NOT_FOUND ? returned
> ----------- ----------- --------------------------- -----------------
> NOT_FOUND NOT_FOUND false ret_loose (NOT_FOUND)
> NOT_FOUND ERROR false ret_loose (ERROR)
> ERROR NOT_FOUND true ret_packed (ERROR)
> ERROR ERROR true ret_packed (ERROR)
>
> So since we return ret_loose as many times as ret_packed. The comment:
>
> > and prefer the error of the packed source in case both reads have
> > failed.
>
> isn't true entirely. So isn't it better modified to something like
> "prefer other errors over not found errors" or something. I hope that
> makes sense?
But we don't. As your above table shows, we return errors twice from the
packed backend and only once from the loose backend. And in case both
sources returned an error, we prefer the packed one.
I think where we're talking past one another is that I distinguish
between errors (-1) and NOT_FOUND.
Patrick
next prev parent reply other threads:[~2026-08-21 5:45 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 14:19 [PATCH 0/7] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 1/7] odb/source: discern missing and corrupt objects Patrick Steinhardt
2026-08-18 18:00 ` Junio C Hamano
2026-08-19 10:01 ` Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 2/7] odb/source-inmemory: signal missing objects via positive return Patrick Steinhardt
2026-08-18 18:05 ` Junio C Hamano
2026-08-19 10:01 ` Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 3/7] odb/source-packed: flag known-bad objects as corrupt and not missing Patrick Steinhardt
2026-08-18 18:17 ` Junio C Hamano
2026-08-19 10:01 ` Patrick Steinhardt
2026-08-19 17:42 ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 4/7] odb/source-loose: distinguish missing and corrupt objects Patrick Steinhardt
2026-08-18 18:23 ` Junio C Hamano
2026-08-18 14:19 ` [PATCH 5/7] odb/source-files: signal mark objects via positive return Patrick Steinhardt
2026-08-18 18:58 ` Junio C Hamano
2026-08-19 10:01 ` Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 6/7] odb/source: allow `read_object_info()` to bubble up error messages Patrick Steinhardt
2026-08-18 14:19 ` [PATCH 7/7] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically Patrick Steinhardt
2026-08-19 12:17 ` [PATCH v2 0/5] " Patrick Steinhardt
2026-08-19 12:17 ` [PATCH v2 1/5] odb/source-packed: flag known-bad objects as corrupt and not missing Patrick Steinhardt
2026-08-19 12:17 ` [PATCH v2 2/5] odb/source: introduce error status when reading objects Patrick Steinhardt
2026-08-20 12:41 ` Karthik Nayak
2026-08-20 14:22 ` Patrick Steinhardt
2026-08-20 20:59 ` Karthik Nayak
2026-08-19 12:17 ` [PATCH v2 3/5] odb/source: let callers discern missing and corrupt objects Patrick Steinhardt
2026-08-20 12:56 ` Karthik Nayak
2026-08-20 14:22 ` Patrick Steinhardt
2026-08-20 21:09 ` Karthik Nayak
2026-08-21 5:45 ` Patrick Steinhardt [this message]
2026-08-21 12:39 ` Karthik Nayak
2026-08-19 12:17 ` [PATCH v2 4/5] odb/source: allow `read_object_info()` to bubble up error messages Patrick Steinhardt
2026-08-19 12:17 ` [PATCH v2 5/5] odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically Patrick Steinhardt
2026-08-20 14:14 ` [PATCH v2 0/5] " Karthik Nayak
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=aofl8e4P6BqJaQEm@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karthik.188@gmail.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;
as well as URLs for NNTP newsgroup(s).