git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 3/8] refs/reftable: read references via `struct reftable_backend`
Date: Tue, 12 Nov 2024 10:05:39 +0100	[thread overview]
Message-ID: <ZzMaY-lqwKIak7Y3@pks.im> (raw)
In-Reply-To: <xmqqed3g6hg1.fsf@gitster.g>

On Tue, Nov 12, 2024 at 04:26:38PM +0900, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Refactor `read_ref_without_reload()` to accept a `struct reftable_stack`
> > as input instead of accepting a `struct reftable_stack`. This allows us
> > to implement an additional caching layer when reading refs where we can
> > reuse reftable iterators.
> >
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> >  refs/reftable-backend.c   | 110 ++++++++++++++++++++------------------
> >  reftable/reftable-stack.h |   3 ++
> >  reftable/stack.c          |   5 ++
> >  3 files changed, 67 insertions(+), 51 deletions(-)
> >
> > diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> > index 4a28dc8a9d..230adb690d 100644
> > --- a/refs/reftable-backend.c
> > +++ b/refs/reftable-backend.c
> > @@ -51,6 +51,50 @@ static void reftable_backend_release(struct reftable_backend *be)
> >  	be->stack = NULL;
> >  }
> >  
> > +static int reftable_backend_read_ref(struct reftable_backend *be,
> > +				     const char *refname,
> > +				     struct object_id *oid,
> > +				     struct strbuf *referent,
> > +				     unsigned int *type)
> > +{
> > +	struct reftable_ref_record ref = {0};
> > +	int ret;
> > +
> > +	ret = reftable_stack_read_ref(be->stack, refname, &ref);
> > +	if (ret)
> > +		goto done;
> > +
> > +	if (ref.value_type == REFTABLE_REF_SYMREF) {
> > +		strbuf_reset(referent);
> > +		strbuf_addstr(referent, ref.value.symref);
> > +		*type |= REF_ISSYMREF;
> > +	} else if (reftable_ref_record_val1(&ref)) {
> > +		unsigned int hash_id;
> > +
> > +		switch (reftable_stack_hash_id(be->stack)) {
> 
> So, relative to the original, instead of relying on the repository
> and its knowledge of what hash function is used, we ask the stack
> what hash function is in use and use that instead.
> 
> > +		case REFTABLE_HASH_SHA1:
> > +			hash_id = GIT_HASH_SHA1;
> > +			break;
> > +		case REFTABLE_HASH_SHA256:
> > +			hash_id = GIT_HASH_SHA256;
> > +			break;
> > +		default:
> > +			BUG("unhandled hash ID %d", reftable_stack_hash_id(be->stack));
> > +		}
> > +
> > +		oidread(oid, reftable_ref_record_val1(&ref),
> > +			&hash_algos[hash_id]);
> > +	} else {
> > +		/* We got a tombstone, which should not happen. */
> > +		BUG("unhandled reference value type %d", ref.value_type);
> > +	}
> > +
> > +done:
> > +	assert(ret != REFTABLE_API_ERROR);
> > +	reftable_ref_record_release(&ref);
> > +	return ret;
> > +}
> 
> Here is the original that got replaced.  Since ...
> 
> > -static int read_ref_without_reload(struct reftable_ref_store *refs,
> > -				   struct reftable_stack *stack,
> > -				   const char *refname,
> > -				   struct object_id *oid,
> > -				   struct strbuf *referent,
> > -				   unsigned int *type)
> > -{
> > -	struct reftable_ref_record ref = {0};
> > -	int ret;
> > -
> > -	ret = reftable_stack_read_ref(stack, refname, &ref);
> > -	if (ret)
> > -		goto done;
> > -
> > -	if (ref.value_type == REFTABLE_REF_SYMREF) {
> > -		strbuf_reset(referent);
> > -		strbuf_addstr(referent, ref.value.symref);
> > -		*type |= REF_ISSYMREF;
> > -	} else if (reftable_ref_record_val1(&ref)) {
> > -		oidread(oid, reftable_ref_record_val1(&ref),
> > -			refs->base.repo->hash_algo);
> 
> ... we have access to "refs", which is a ref_store, that knows its
> repository, it was just a few pointer references away to get the
> hash id of the Git side.  But of course we use REFTABLE_HASH_*NAME*
> to identify the algorithm at this layer, so we need to translate it
> back to the ide on the Git side before asking oidread() to read it.
> 
> > -	} else {
> > -		/* We got a tombstone, which should not happen. */
> > -		BUG("unhandled reference value type %d", ref.value_type);
> > -	}
> > -
> > -done:
> > -	assert(ret != REFTABLE_API_ERROR);
> > -	reftable_ref_record_release(&ref);
> > -	return ret;
> > -}
> 
> There is one thing that is curious about this step.
> 
> It isn't like we teach stack what hash it uses in this step---the
> reftable_stack_hash_id() could have been implemented as early as
> 59343984 (reftable/system: stop depending on "hash.h", 2024-11-08).

In theory we could've implemented it even earlier than that: the commit
only introduces the reftable-specific hashes, and we had the
Git-specific hashes available before that. Like that we wouldn't even
have to translate between the different hashes in the first place.

> Other than that this step introduces the first caller of
> reftable_stack_hash_id() in the series, the remaining hunks of this
> patch do not have to be part of this patch, but could have been a
> separate step.  Not a suggestion to split it out, but merely an
> observation (to make sure I am reading the code correctly).

Yup, your understanding matches mine.

Patrick

  reply	other threads:[~2024-11-12  9:05 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 15:11 [PATCH 0/8] refs/reftable: reuse iterators when reading refs Patrick Steinhardt
2024-11-04 15:11 ` [PATCH 1/8] refs/reftable: encapsulate reftable stack Patrick Steinhardt
2024-11-05 11:03   ` karthik nayak
2024-11-04 15:11 ` [PATCH 2/8] refs/reftable: handle reloading stacks in the reftable backend Patrick Steinhardt
2024-11-05 11:14   ` karthik nayak
2024-11-06 10:43     ` Patrick Steinhardt
2024-11-04 15:11 ` [PATCH 3/8] refs/reftable: read references via `struct reftable_backend` Patrick Steinhardt
2024-11-05 11:20   ` karthik nayak
2024-11-04 15:11 ` [PATCH 4/8] refs/reftable: refactor reading symbolic refs to use reftable backend Patrick Steinhardt
2024-11-04 15:11 ` [PATCH 5/8] refs/reftable: refactor reflog expiry " Patrick Steinhardt
2024-11-04 15:11 ` [PATCH 6/8] reftable/stack: add mechanism to notify callers on reload Patrick Steinhardt
2024-11-04 15:11 ` [PATCH 7/8] reftable/merged: drain priority queue on reseek Patrick Steinhardt
2024-11-05  3:16   ` Junio C Hamano
2024-11-05  3:23     ` Junio C Hamano
2024-11-05  7:14       ` Patrick Steinhardt
2024-11-04 15:11 ` [PATCH 8/8] refs/reftable: reuse iterators when reading refs Patrick Steinhardt
2024-11-05  4:49 ` [PATCH 0/8] " Junio C Hamano
2024-11-05  9:11 ` [PATCH v2 " Patrick Steinhardt
2024-11-05  9:11   ` [PATCH v2 1/8] refs/reftable: encapsulate reftable stack Patrick Steinhardt
2024-11-12  6:07     ` Junio C Hamano
2024-11-05  9:12   ` [PATCH v2 2/8] refs/reftable: handle reloading stacks in the reftable backend Patrick Steinhardt
2024-11-12  6:41     ` Junio C Hamano
2024-11-12  9:05       ` Patrick Steinhardt
2024-11-05  9:12   ` [PATCH v2 3/8] refs/reftable: read references via `struct reftable_backend` Patrick Steinhardt
2024-11-12  7:26     ` Junio C Hamano
2024-11-12  9:05       ` Patrick Steinhardt [this message]
2024-11-05  9:12   ` [PATCH v2 4/8] refs/reftable: refactor reading symbolic refs to use reftable backend Patrick Steinhardt
2024-11-05  9:12   ` [PATCH v2 5/8] refs/reftable: refactor reflog expiry " Patrick Steinhardt
2024-11-05  9:12   ` [PATCH v2 6/8] reftable/stack: add mechanism to notify callers on reload Patrick Steinhardt
2024-11-05  9:12   ` [PATCH v2 7/8] reftable/merged: drain priority queue on reseek Patrick Steinhardt
2024-11-05  9:12   ` [PATCH v2 8/8] refs/reftable: reuse iterators when reading refs Patrick Steinhardt
2024-11-25  7:38 ` [PATCH v3 0/9] " Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 1/9] refs/reftable: encapsulate reftable stack Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 2/9] refs/reftable: handle reloading stacks in the reftable backend Patrick Steinhardt
2024-11-26  0:31     ` Junio C Hamano
2024-11-25  7:38   ` [PATCH v3 3/9] reftable/stack: add accessor for the hash ID Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 4/9] refs/reftable: read references via `struct reftable_backend` Patrick Steinhardt
2024-11-26  0:48     ` Junio C Hamano
2024-11-26  6:41       ` Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 5/9] refs/reftable: refactor reading symbolic refs to use reftable backend Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 6/9] refs/reftable: refactor reflog expiry " Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 7/9] reftable/stack: add mechanism to notify callers on reload Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 8/9] reftable/merged: drain priority queue on reseek Patrick Steinhardt
2024-11-25  7:38   ` [PATCH v3 9/9] refs/reftable: reuse iterators when reading refs Patrick Steinhardt
2024-11-25  9:47   ` [PATCH v3 0/9] " Christian Couder
2024-11-25  9:52     ` Patrick Steinhardt
2024-11-26  6:42 ` [PATCH v4 00/10] " Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 01/10] refs/reftable: encapsulate reftable stack Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 02/10] refs/reftable: handle reloading stacks in the reftable backend Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 03/10] reftable/stack: add accessor for the hash ID Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 04/10] refs/reftable: figure out hash via `reftable_stack` Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 05/10] refs/reftable: read references via `struct reftable_backend` Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 06/10] refs/reftable: refactor reading symbolic refs to use reftable backend Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 07/10] refs/reftable: refactor reflog expiry " Patrick Steinhardt
2024-11-26  6:42   ` [PATCH v4 08/10] reftable/stack: add mechanism to notify callers on reload Patrick Steinhardt
2024-11-26  6:43   ` [PATCH v4 09/10] reftable/merged: drain priority queue on reseek Patrick Steinhardt
2024-11-26  6:43   ` [PATCH v4 10/10] refs/reftable: reuse iterators when reading refs 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=ZzMaY-lqwKIak7Y3@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).