From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/7] setup: extract function to create the refdb
Date: Thu, 7 Dec 2023 08:22:59 +0100 [thread overview]
Message-ID: <ZXFy0_T1AZLh058g@tanuki> (raw)
In-Reply-To: <CAOLa=ZSZztJUF9nmSzGdOW0oWBRUp2sw8QyuZO_q06cNymad3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]
On Wed, Dec 06, 2023 at 10:10:37PM +0100, Karthik Nayak wrote:
> On Wed, Dec 6, 2023 at 1:40 PM Patrick Steinhardt <ps@pks.im> wrote:
> > +static void create_reference_database(const char *initial_branch, int quiet)
> > +{
> > + struct strbuf err = STRBUF_INIT;
> > + int reinit = is_reinit();
> > +
> > + /*
> > + * We need to create a "refs" dir in any case so that older
> > + * versions of git can tell that this is a repository.
> > + */
>
> How does this work though, even if an earlier version of git can tell
> that this is a repository, it still won't be able to read the reftable
> backend. In that sense, what do we achieve here?
This is a good question, and there is related ongoing discussion about
this topic in the thread starting at [1]. There are a few benefits to
letting clients discover such repos even if they don't understand the
new reference backend format:
- They know to stop walking up the parent-directory chain. Otherwise a
client might end up detecting a Git repository in the parent dir.
- The user gets a proper error message why the repository cannot be
accessed. Instead of failing to detect the repository altogether we
instead say that we don't understand the "extensions.refFormat"
extension.
Maybe there are other cases I can't think of right now.
> > + safe_create_dir(git_path("refs"), 1);
> > + adjust_shared_perm(git_path("refs"));
> > +
>
> Not related to your commit per se, but we ignore the return value
> here, shouldn't we die in this case?
While the end result wouldn't be quite what the user asks for, the only
negative consequence is that the repository is inaccessible to others. I
think this failure mode is comparatively benign -- if it were the other
way round and we'd over-share the repository it would more severe.
So while I don't think that dying makes much sense here, I could
certainly see us adding a warning so that the user at least knows that
something went wrong. I'd rather want to keep this out of the current
patch series, but could certainly see such a warning added in a follow
up patch series.
Patrick
[1]: <ZWcOvjGPVS_CMUAk@tanuki>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-12-07 7:23 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 12:39 [PATCH 0/7] clone: fix init of refdb with wrong object format Patrick Steinhardt
2023-12-06 12:39 ` [PATCH 1/7] setup: extract function to create the refdb Patrick Steinhardt
2023-12-06 21:10 ` Karthik Nayak
2023-12-07 7:22 ` Patrick Steinhardt [this message]
2023-12-08 22:54 ` Junio C Hamano
2023-12-11 11:34 ` Patrick Steinhardt
2023-12-11 15:50 ` Karthik Nayak
2023-12-06 12:39 ` [PATCH 2/7] setup: allow skipping creation of " Patrick Steinhardt
2023-12-06 12:39 ` [PATCH 3/7] remote-curl: rediscover repository when fetching refs Patrick Steinhardt
2023-12-08 23:09 ` Junio C Hamano
2023-12-11 11:35 ` Patrick Steinhardt
2023-12-06 12:40 ` [PATCH 4/7] builtin/clone: fix bundle URIs with mismatching object formats Patrick Steinhardt
2023-12-06 21:13 ` Karthik Nayak
2023-12-07 7:22 ` Patrick Steinhardt
2023-12-08 23:11 ` Junio C Hamano
2023-12-06 12:40 ` [PATCH 5/7] builtin/clone: set up sparse checkout later Patrick Steinhardt
2023-12-06 12:40 ` [PATCH 6/7] builtin/clone: skip reading HEAD when retrieving remote Patrick Steinhardt
2023-12-06 12:40 ` [PATCH 7/7] builtin/clone: create the refdb with the correct object format Patrick Steinhardt
2023-12-06 13:09 ` [PATCH 0/7] clone: fix init of refdb with wrong " Patrick Steinhardt
2023-12-10 3:16 ` Junio C Hamano
2023-12-11 11:34 ` Patrick Steinhardt
2023-12-11 14:57 ` Junio C Hamano
2023-12-11 15:32 ` Patrick Steinhardt
2023-12-11 22:17 ` brian m. carlson
2023-12-12 7:00 ` [PATCH v2 " Patrick Steinhardt
2023-12-12 7:00 ` [PATCH v2 1/7] setup: extract function to create the refdb Patrick Steinhardt
2023-12-12 7:00 ` [PATCH v2 2/7] setup: allow skipping creation of " Patrick Steinhardt
2023-12-12 7:00 ` [PATCH v2 3/7] remote-curl: rediscover repository when fetching refs Patrick Steinhardt
2023-12-12 7:00 ` [PATCH v2 4/7] builtin/clone: fix bundle URIs with mismatching object formats Patrick Steinhardt
2023-12-12 7:00 ` [PATCH v2 5/7] builtin/clone: set up sparse checkout later Patrick Steinhardt
2023-12-12 7:01 ` [PATCH v2 6/7] builtin/clone: skip reading HEAD when retrieving remote Patrick Steinhardt
2023-12-12 7:01 ` [PATCH v2 7/7] builtin/clone: create the refdb with the correct object format Patrick Steinhardt
2023-12-12 19:20 ` [PATCH v2 0/7] clone: fix init of refdb with wrong " 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=ZXFy0_T1AZLh058g@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).