All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH v2 03/12] refs: refactor logic to look up storage backends
Date: Thu, 28 Dec 2023 21:11:30 +0100	[thread overview]
Message-ID: <ZY3Wcua6dtzO2jG4@framework> (raw)
In-Reply-To: <xmqqjzoygrx8.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On Thu, Dec 28, 2023 at 09:25:55AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > In order to look up ref storage backends, we're currently using a linked
> > list of backends, where each backend is expected to set up its `next`
> > pointer to the next ref storage backend. This is kind of a weird setup
> > as backends need to be aware of other backends without much of a reason.
> >
> > Refactor the code so that the array of backends is centrally defined in
> > "refs.c", where each backend is now identified by an integer constant.
> > Expose functions to translate from those integer constants to the name
> > and vice versa, which will be required by subsequent patches.
> 
> A small question.  Does this have to be "int", or is "unsigned" (or
> even an enum, rewrittenfrom the "REF_STORAGE_FORMAT_*" family of CPP
> macro constants) good enough?  I am only wondering what happens when
> you clal find_ref_storage_backend() with a negative index.

No, it does not have to be an `int`, and handling a negative index would
be a bug. I tried to stick to what we have with `GIT_HASH_UNKNOWN`,
`GIT_HASH_SHA1` etc, which is exactly similar in spirit. Whether it's
the perfect way to handle this... probably not. Without the context I
would've used an `enum`, but instead I opted for consistency.

> For that matter, how REF_STORAGE_FORMAT_UNKNOWN (whose value is 0)
> is handled by the function also gets curious.  The caller may have
> to find that the backend hasn't been specified by receiving an
> element in the refs_backends[] array that corresponds to it, but the
> error behaviour of this function is also to return NULL, so it has
> to be prepared to handle both cases?

Yeah, we do not really discern those two cases for now and instead just
return `NULL` both for any unknown ref storage format. All callers know
to handle `NULL`, but the error handling will only report a generic
"unknown" backend error.

The easiest way to discern those cases would be to `BUG()` when being
passed an invalid ref storage format smaller than 0 or larger than the
number of known backends. Because ultimately it is just that, a bug that
shouldn't ever occur.

Not sure whether this is worth a reroll?

Patrick

> > +static const struct ref_storage_be *refs_backends[] = {
> > +	[REF_STORAGE_FORMAT_FILES] = &refs_be_files,
> > +};
> > ...
> > +static const struct ref_storage_be *find_ref_storage_backend(int ref_storage_format)
> >  {
> > +	if (ref_storage_format < ARRAY_SIZE(refs_backends))
> > +		return refs_backends[ref_storage_format];
> >  	return NULL;
> >  }

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-12-28 20:11 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20 10:54 [PATCH 00/12] Introduce `refStorage` extension Patrick Steinhardt
2023-12-20 10:54 ` [PATCH 01/12] t: introduce DEFAULT_REPO_FORMAT prereq Patrick Steinhardt
2023-12-22 11:41   ` Karthik Nayak
2023-12-28  8:55     ` Patrick Steinhardt
2023-12-20 10:54 ` [PATCH 02/12] worktree: skip reading HEAD when repairing worktrees Patrick Steinhardt
2023-12-22 12:23   ` Karthik Nayak
2023-12-20 10:55 ` [PATCH 03/12] refs: refactor logic to look up storage backends Patrick Steinhardt
2023-12-22 12:38   ` Karthik Nayak
2023-12-28  8:56     ` Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 04/12] setup: start tracking ref storage format when Patrick Steinhardt
2023-12-20 18:30   ` Junio C Hamano
2023-12-28  8:56     ` Patrick Steinhardt
2023-12-28 17:15       ` Junio C Hamano
2023-12-28 20:01         ` Patrick Steinhardt
2023-12-22 13:09   ` Karthik Nayak
2023-12-28  8:56     ` Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 05/12] setup: set repository's formats on init Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 06/12] setup: introduce "extensions.refStorage" extension Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 07/12] setup: introduce GIT_DEFAULT_REF_FORMAT envvar Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 08/12] t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 09/12] builtin/rev-parse: introduce `--show-ref-format` flag Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 10/12] builtin/init: introduce `--ref-format=` value flag Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 11/12] builtin/clone: " Patrick Steinhardt
2023-12-20 10:55 ` [PATCH 12/12] t9500: write "extensions.refstorage" into config Patrick Steinhardt
2023-12-22 13:43   ` Karthik Nayak
2023-12-22 13:43 ` [PATCH 00/12] Introduce `refStorage` extension Karthik Nayak
2023-12-26 20:56   ` Junio C Hamano
2023-12-28  9:57 ` [PATCH v2 " Patrick Steinhardt
2023-12-28  9:57   ` [PATCH v2 01/12] t: introduce DEFAULT_REPO_FORMAT prereq Patrick Steinhardt
2023-12-28  9:57   ` [PATCH v2 02/12] worktree: skip reading HEAD when repairing worktrees Patrick Steinhardt
2023-12-28 18:08     ` Eric Sunshine
2023-12-28 18:13       ` Eric Sunshine
2023-12-28 20:18         ` Patrick Steinhardt
2023-12-28  9:57   ` [PATCH v2 03/12] refs: refactor logic to look up storage backends Patrick Steinhardt
2023-12-28 17:25     ` Junio C Hamano
2023-12-28 20:11       ` Patrick Steinhardt [this message]
2023-12-28 20:42         ` Junio C Hamano
2023-12-28  9:57   ` [PATCH v2 04/12] setup: start tracking ref storage format Patrick Steinhardt
2023-12-28  9:57   ` [PATCH v2 05/12] setup: set repository's formats on init Patrick Steinhardt
2023-12-28  9:57   ` [PATCH v2 06/12] setup: introduce "extensions.refStorage" extension Patrick Steinhardt
2023-12-28  9:57   ` [PATCH v2 07/12] setup: introduce GIT_DEFAULT_REF_FORMAT envvar Patrick Steinhardt
2023-12-28  9:57   ` [PATCH v2 08/12] t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar Patrick Steinhardt
2023-12-28  9:58   ` [PATCH v2 09/12] builtin/rev-parse: introduce `--show-ref-format` flag Patrick Steinhardt
2023-12-28  9:58   ` [PATCH v2 10/12] builtin/init: introduce `--ref-format=` value flag Patrick Steinhardt
2023-12-28  9:58   ` [PATCH v2 11/12] builtin/clone: " Patrick Steinhardt
2023-12-28  9:58   ` [PATCH v2 12/12] t9500: write "extensions.refstorage" into config Patrick Steinhardt
2023-12-29  7:26 ` [PATCH v3 00/12] Introduce `refStorage` extension Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 01/12] t: introduce DEFAULT_REPO_FORMAT prereq Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 02/12] worktree: skip reading HEAD when repairing worktrees Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 03/12] refs: refactor logic to look up storage backends Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 04/12] setup: start tracking ref storage format Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 05/12] setup: set repository's formats on init Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 06/12] setup: introduce "extensions.refStorage" extension Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 07/12] setup: introduce GIT_DEFAULT_REF_FORMAT envvar Patrick Steinhardt
2023-12-29  7:26   ` [PATCH v3 08/12] t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar Patrick Steinhardt
2023-12-29  7:27   ` [PATCH v3 09/12] builtin/rev-parse: introduce `--show-ref-format` flag Patrick Steinhardt
2023-12-29  7:27   ` [PATCH v3 10/12] builtin/init: introduce `--ref-format=` value flag Patrick Steinhardt
2023-12-29  7:27   ` [PATCH v3 11/12] builtin/clone: " Patrick Steinhardt
2023-12-29  7:27   ` [PATCH v3 12/12] t9500: write "extensions.refstorage" into config Patrick Steinhardt
2023-12-29  8:44   ` [PATCH v3 00/12] Introduce `refStorage` extension Eric Sunshine

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=ZY3Wcua6dtzO2jG4@framework \
    --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.