Git development
 help / color / mirror / Atom feed
From: Justin Tobler <jltobler@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/6] odb: add `source` field to struct object_info_source
Date: Mon, 29 Jun 2026 12:49:08 -0500	[thread overview]
Message-ID: <akKtc4ybxFRVJmNv@denethor> (raw)
In-Reply-To: <20260624-b4-pks-odb-drop-whence-v1-3-8d1877b790ac@pks.im>

On 26/06/24 02:19PM, Patrick Steinhardt wrote:
> The previous commit introduced `struct object_info_source` as an opt-in
> container for backend-specific information, but for now we only moved
> preexisting data into this structure. Most importantly, the caller has
> no way yet to learn about which source an object was actually looked up
> from. Instead, callers have to rely on the `whence` enum to distinguish
> the object type, but cannot use that enum to tell the object source.
> 
> Add a `struct odb_source *source` field to the structure and populate it
> from each backend's lookup path.

Makes sense.

> The `whence` enum is still set and used by callers; it will be removed
> in a subsequent commit now that `sourcep->source` can identify the
> backend on its own.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  odb.h                 | 3 +++
>  odb/source-inmemory.c | 3 +++
>  odb/source-loose.c    | 2 ++
>  packfile.c            | 6 +++++-
>  4 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/odb.h b/odb.h
> index 770900289a..330a55879e 100644
> --- a/odb.h
> +++ b/odb.h
> @@ -253,6 +253,9 @@ int odb_pretend_object(struct object_database *odb,
>   * more about how exactly it is stored.
>   */
>  struct object_info_source {
> +	/* The source that this object has been looked up from. */
> +	struct odb_source *source;

Here we add the `struct odb_source` so we can begin recording it.

> +
>  	/*
>  	 * Backend-specific information about the specific object. This can be
>  	 * used for example to uniquely identify a given object in case it
> diff --git a/odb/source-inmemory.c b/odb/source-inmemory.c
> index e004566d76..2328e62687 100644
> --- a/odb/source-inmemory.c
> +++ b/odb/source-inmemory.c
> @@ -52,6 +52,9 @@ static void populate_object_info(struct odb_source_inmemory *source,
>  		*oi->contentp = xmemdupz(object->buf, object->size);
>  	if (oi->mtimep)
>  		*oi->mtimep = 0;
> +	if (oi->sourcep)
> +		oi->sourcep->source = &source->base;

Here we set the source for the in-memory backend.

> +
>  	oi->whence = OI_CACHED;
>  }
>  
> diff --git a/odb/source-loose.c b/odb/source-loose.c
> index 66e6bb8d3f..5c4e9892b5 100644
> --- a/odb/source-loose.c
> +++ b/odb/source-loose.c
> @@ -196,6 +196,8 @@ static int read_object_info_from_path(struct odb_source_loose *loose,
>  			oi->typep = NULL;
>  		if (oi->delta_base_oid)
>  			oidclr(oi->delta_base_oid, loose->base.odb->repo->hash_algo);
> +		if (oi->sourcep && !ret)
> +			oi->sourcep->source = &loose->base;

Here it is set for the loose backend.

>  		if (!ret)
>  			oi->whence = OI_LOOSE;
>  	}
> diff --git a/packfile.c b/packfile.c
> index 688c410b35..fa22095b75 100644
> --- a/packfile.c
> +++ b/packfile.c
> @@ -1324,7 +1324,7 @@ static void add_delta_base_cache(struct packed_git *p, off_t base_offset,
>  	hashmap_add(&delta_base_cache, &ent->ent);
>  }
>  
> -int packed_object_info_with_index_pos(struct odb_source_packed *source UNUSED,
> +int packed_object_info_with_index_pos(struct odb_source_packed *source,
>  				      struct packed_git *p, off_t obj_offset,
>  				      uint32_t *maybe_index_pos, struct object_info *oi)
>  {
> @@ -1424,6 +1424,10 @@ int packed_object_info_with_index_pos(struct odb_source_packed *source UNUSED,
>  	oi->whence = OI_PACKED;
>  
>  	if (oi->sourcep) {
> +		if (!source)
> +			BUG("cannot request source without an owning source");
> +		oi->sourcep->source = &source->base;

And here it is set for the packed backend. Looks good.

Naive question: I understand that some `packed_info_object()` callers
may not have the `struct odb_source` on hand, but when the `struct
packed_git` is intially setup, is it not always known the ODB source it
comes from? It makes me wonder if the ODB source should also be recorded
when `struct packed_git` is initialized.

-Justin

  reply	other threads:[~2026-06-29 17:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24 12:19 [PATCH 0/6] odb: refactor source-specific information in object info Patrick Steinhardt
2026-06-24 12:19 ` [PATCH 1/6] packfile: thread odb_source_packed through packed_object_info() Patrick Steinhardt
2026-06-29 17:01   ` Justin Tobler
2026-06-24 12:19 ` [PATCH 2/6] odb: make backend-specific fields optional Patrick Steinhardt
2026-06-29 17:25   ` Justin Tobler
2026-06-24 12:19 ` [PATCH 3/6] odb: add `source` field to struct object_info_source Patrick Steinhardt
2026-06-29 17:49   ` Justin Tobler [this message]
2026-06-24 12:19 ` [PATCH 4/6] treewide: convert users of `whence` to the new source field Patrick Steinhardt
2026-06-29 17:55   ` Justin Tobler
2026-06-24 12:19 ` [PATCH 5/6] odb: drop `whence` field from object info Patrick Steinhardt
2026-06-29 17:57   ` Justin Tobler
2026-06-24 12:19 ` [PATCH 6/6] odb: document object info fields Patrick Steinhardt
2026-06-24 17:13 ` [PATCH 0/6] odb: refactor source-specific information in object info Junio C Hamano

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=akKtc4ybxFRVJmNv@denethor \
    --to=jltobler@gmail.com \
    --cc=git@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox