From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/6] setup: move creation of "refs/" into the files backend
Date: Wed, 3 Jan 2024 09:33:22 +0100 [thread overview]
Message-ID: <ZZUb0rj7be6wLQz5@tanuki> (raw)
In-Reply-To: <CAOLa=ZTR6aW5aoxcMOS3U3TL1VxSfmyVno9fu7B5201pJTqyyg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
On Tue, Jan 02, 2024 at 05:23:18AM -0800, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > Move the code to create the directory into the files backend itself to
> > make it so. This means that future ref backends will also need to have
> > equivalent logic around to ensure that the directory exists, but it
> > seems a lot more sensible to have it this way round than to require
> > callers to create the directory themselves.
> >
>
> Why not move it to refs.c:refs_init_db() instead? this way each
> implementation doesn't have to do it?
True, that would be another possibility. But I think it is conceptually
unclean to split up creation of the refdb into multiple locations. The
"files" backend already has to create "refs/heads/" and "refs/tags/",
and the "reftable" backend will set up "refs/heads" as a file so that
it's impossible to create branches as loose files by accident. So both
do have specific knowledge around how exactly this directory hierarchy
should look like, and thus I think it is sensible to make the code self
contained inside of the backends.
My opinion on this would be different if we expected a proliferation of
backends to happen, but that's quite unlikely. Furthermore, we may at
some point decide that repos don't need "refs/" and/or "HEAD" at all
anymore, at which point it is easier to drop the creation of those files
and dirs from the reftable backend.
I'll update the commit message to include these considerations.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-03 8:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-28 9:59 [PATCH 0/6] worktree: initialize refdb via ref backends Patrick Steinhardt
2023-12-28 9:59 ` [PATCH 1/6] refs: prepare `refs_init_db()` for initializing worktree refs Patrick Steinhardt
2023-12-28 9:59 ` [PATCH 2/6] setup: move creation of "refs/" into the files backend Patrick Steinhardt
2024-01-02 13:23 ` Karthik Nayak
2024-01-03 8:33 ` Patrick Steinhardt [this message]
2023-12-28 10:00 ` [PATCH 3/6] refs/files: skip creation of "refs/{heads,tags}" for worktrees Patrick Steinhardt
2023-12-29 10:35 ` Eric Sunshine
2023-12-28 10:00 ` [PATCH 4/6] builtin/worktree: move setup of commondir file earlier Patrick Steinhardt
2023-12-28 10:00 ` [PATCH 5/6] worktree: expose interface to look up worktree by name Patrick Steinhardt
2023-12-28 10:00 ` [PATCH 6/6] builtin/worktree: create refdb via ref backend Patrick Steinhardt
2023-12-28 18:11 ` [PATCH 0/6] worktree: initialize refdb via ref backends Junio C Hamano
2023-12-28 19:57 ` Patrick Steinhardt
2024-01-08 10:05 ` [PATCH v2 " Patrick Steinhardt
2024-01-08 10:05 ` [PATCH v2 1/6] refs: prepare `refs_init_db()` for initializing worktree refs Patrick Steinhardt
2024-01-08 10:05 ` [PATCH v2 2/6] setup: move creation of "refs/" into the files backend Patrick Steinhardt
2024-01-08 10:05 ` [PATCH v2 3/6] refs/files: skip creation of "refs/{heads,tags}" for worktrees Patrick Steinhardt
2024-01-08 10:05 ` [PATCH v2 4/6] builtin/worktree: move setup of commondir file earlier Patrick Steinhardt
2024-01-08 10:05 ` [PATCH v2 5/6] worktree: expose interface to look up worktree by name Patrick Steinhardt
2024-01-08 10:05 ` [PATCH v2 6/6] builtin/worktree: create refdb via ref backend Patrick Steinhardt
2024-01-16 9:17 ` [PATCH v2 0/6] worktree: initialize refdb via ref backends Karthik Nayak
2024-01-16 17:53 ` 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=ZZUb0rj7be6wLQz5@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--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 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).