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
Subject: Re: [PATCH 02/16] refs: rename `init_db` callback to avoid confusion
Date: Fri, 17 May 2024 09:08:47 +0200	[thread overview]
Message-ID: <ZkcCf7kTfMkuANS4@tanuki> (raw)
In-Reply-To: <xmqqa5kpr4wr.fsf@gitster.g>

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

On Thu, May 16, 2024 at 11:24:36AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Reference backends have two callbacks `init` and `init_db`. The
> > similarity of these two callbacks has repeatedly tripped myself whenever
> > I was looking at those, where I always had to look up which of them does
> > what.
> >
> > Rename the `init_db` callback to `create`, which should hopefully be
> > clearer.
> 
> Hmph, create() may be clearer than init_db(), but then I am not sure
> what init() would do, differently from create(), so this rename
> takes me back to the puzzled square one state X-<.
> 
> I am guessing that create is about creating on-disk structure, while
> init is about in-core structure out of an existing on-disk
> structure?  Once I understand the differences in these two things,
> it is much less troublesome to tell them apart, regardless of what
> they are called.  Between .init and .init_db, it would be obvious
> that the latter is about on-disk thing, without a rename done by
> this step.  On the other hand, contrast between <create, init> is
> just as opaque as <init_db, init>---the names do not tell readers
> that these two are about on-disk and in-core structures.
> 
> Just my confused impression.

I certainly wouldn't claim that `create()` vs `init()` is perfect,
either. We could easily avoid that confusion if we were happy to make it
more verbose, e.g. by calling it `create_on_disk()`. I don't really
think that we also need to do the same for `init()`, mostly because it
is a common idiom in our codebase to have `init()` initialize data
structures. But that may also be my own personal bias.

I'll go with `create_on_disk()` for now. It's more verbose, but given
that this function isn't called all that much I think it's fine overall.

Patrick

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

  reply	other threads:[~2024-05-17  7:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16  8:04 [PATCH 00/16] refs: drop all references to `the_repository` Patrick Steinhardt
2024-05-16  8:04 ` [PATCH 01/16] refs: adjust names for `init` and `init_db` callbacks Patrick Steinhardt
2024-05-16 14:50   ` Karthik Nayak
2024-05-16  8:04 ` [PATCH 02/16] refs: rename `init_db` callback to avoid confusion Patrick Steinhardt
2024-05-16 15:00   ` Karthik Nayak
2024-05-16 18:24   ` Junio C Hamano
2024-05-17  7:08     ` Patrick Steinhardt [this message]
2024-05-16  8:04 ` [PATCH 03/16] refs: implement releasing ref storages Patrick Steinhardt
2024-05-16 16:39   ` Karthik Nayak
2024-05-16 18:01     ` Junio C Hamano
2024-05-17  7:09       ` Patrick Steinhardt
2024-05-17  7:08     ` Patrick Steinhardt
2024-05-16  8:04 ` [PATCH 04/16] refs: track ref stores via strmap Patrick Steinhardt
2024-05-16 18:34   ` Junio C Hamano
2024-05-16  8:04 ` [PATCH 05/16] refs: pass repo when retrieving submodule ref store Patrick Steinhardt
2024-05-16 18:44   ` Junio C Hamano
2024-05-17  7:09     ` Patrick Steinhardt
2024-05-16  8:04 ` [PATCH 06/16] refs: refactor `resolve_gitlink_ref()` to accept a repository Patrick Steinhardt
2024-05-16 18:45   ` Junio C Hamano
2024-05-16  8:04 ` [PATCH 07/16] refs: retrieve worktree ref stores via associated repository Patrick Steinhardt
2024-05-16  8:04 ` [PATCH 08/16] refs: convert iteration over replace refs to accept ref store Patrick Steinhardt
2024-05-16  8:04 ` [PATCH 09/16] refs: pass ref store when detecting dangling symrefs Patrick Steinhardt
2024-05-16  8:04 ` [PATCH 10/16] refs: move object peeling into "object.c" Patrick Steinhardt
2024-05-16 20:55   ` Junio C Hamano
2024-05-16  8:05 ` [PATCH 11/16] refs: pass repo when peeling objects Patrick Steinhardt
2024-05-16  8:05 ` [PATCH 12/16] refs: drop `git_default_branch_name()` Patrick Steinhardt
2024-05-16 18:44   ` Karthik Nayak
2024-05-16  8:05 ` [PATCH 13/16] refs: remove `dwim_log()` Patrick Steinhardt
2024-05-16  8:05 ` [PATCH 14/16] refs/files: use correct repository Patrick Steinhardt
2024-05-16  8:05 ` [PATCH 15/16] refs/files: remove references to `the_hash_algo` Patrick Steinhardt
2024-05-16  8:05 ` [PATCH 16/16] refs/packed: " Patrick Steinhardt
2024-05-16 18:57 ` [PATCH 00/16] refs: drop all references to `the_repository` Karthik Nayak
2024-05-17  7:08   ` 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=ZkcCf7kTfMkuANS4@tanuki \
    --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 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.