All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-08-21  5:45 UTC|newest]

Thread overview: 32+ 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-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 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.