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: Thu, 20 Aug 2026 16:22:41 +0200	[thread overview]
Message-ID: <aocNsR60-8W2A-fy@pks.im> (raw)
In-Reply-To: <CAOLa=ZSSzR+qKh4Do-F7xZQMO-pE+t4N8qM5hsbfM4Uh7i3d1A@mail.gmail.com>

On Thu, Aug 20, 2026 at 08:56:50AM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/odb/source-files.c b/odb/source-files.c
> > index a28aa5042d..e88fd1d399 100644
> > --- a/odb/source-files.c
> > +++ b/odb/source-files.c
> > @@ -65,12 +65,26 @@ static enum odb_read_status odb_source_files_read_object_info(struct odb_source
> >  							      enum object_info_flags flags)
> >  {
> >  	struct odb_source_files *files = odb_source_files_downcast(source);
> > +	enum odb_read_status ret_packed, ret_loose;
> >
> > -	if (!odb_source_read_object_info(&files->packed->base, oid, oi, flags) ||
> > -	    !odb_source_read_object_info(&files->loose->base, oid, oi, flags))
> > +	ret_packed = odb_source_read_object_info(&files->packed->base, oid, oi, flags);
> > +	if (!ret_packed)
> >  		return 0;
> >
> 
> Nit: Similar to my previous comment, wouldn't it be nicer to do
> 
>      if (ret_packed == ODB_READ_OK)
>         return 0;

As mentioned in the preceding commit, I think it would be somewhat
pointless and only make the code more verbose without much of a purpose.

> > -	return -1;
> > +	ret_loose = odb_source_read_object_info(&files->loose->base, oid, oi, flags);
> > +	if (!ret_loose)
> > +		return 0;
> > +
> > +	/*
> > +	 * Reading the packed object may have failed even though the object
> > +	 * exists, for example because it is corrupt. Report this failure to
> > +	 * the caller in case neither of the sources was able to read the
> > +	 * object, and prefer the error of the packed source in case both
> > +	 * reads have failed.
> > +	 */
> > +	if (ret_packed != ODB_READ_NOT_FOUND)
> > +		return ret_packed;
> > +	return ret_loose;
> >  }
> >
> 
> So if we already found the source we return early and only come here for
> errors. What I don't understand is why we filter out ODB_READ_NOT_FOUND
> for packed. Wouldn't that leave us with
> 
>     ret_packed => ODB_READ_ERROR
>     ret_loose  => ODB_READ_ERROR or ODB_READ_NOT_FOUND
> 
> Doesn't this come down to preferring to propagate ODB_READ_NOT_FOUND over
> ODB_READ_ERROR and now packed error over loose?

So here we know that we didn't find the object. So there's four cases:

  - The object was not found in either, and we'll return
    ODB_READ_NOT_FOUND.

  - The object was not found in the "packed" source but was found in the
    "loose" source. So we'd have `ret_packed == ODB_READ_NOT_FOUND` and
    `ret_loose` at any other error code. And consequently this block:

        if (ret_packed != ODB_READ_NOT_FOUND)
            return ret_packed;

    Would not trigger as `ret_packed` _is_ ODB_READ_NOT_FOUND. Hence, we
    favor the error from `ret_loose`, which contains our corruption
    error.

  - The reverse case, where the object exists in the "packed" backend
    but is corrupt. In that case `ret_packed != ODB_READ_NOT_FOUND`
    evaluates true, and we bubble up that error.

  - Both sources have a corrupt object. If so, we simply favor the
    packed error because we have to pick one.

I think you've simply misread the condition, as we do exactly the
reverse.

Patrick

  reply	other threads:[~2026-08-20 14:22 UTC|newest]

Thread overview: 29+ 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-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 [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=aocNsR60-8W2A-fy@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.