Re: [PATCH v2 2/5] create .git/refs in files-backend.c
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 27, 2020, 22:28 UTC
- Message-ID
- <xmqqr1zka616.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <d7d642dcf6f3c661c51302d02c69e781e201cc6e.1580134944.git.gitgitgadget@gmail.com>
"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 5 quoted lines
> From: Han-Wen Nienhuys <hanwen@google.com> > Subject: Re: [PATCH v2 2/5] create .git/refs in files-backend.c > > This prepares for supporting the reftable format, which creates a file > in that place.
The idea is sound, I think. We want to let each backend to be responsible for creating and maintaining what is at .git/refs on the filesystem.
> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> Change-Id: I2fc47c89f5ec605734007ceff90321c02474aa92
Do we need to keep this, which is pretty much private name for the patch that is not valid for most of the people on the list?
Show 29 quoted lines
> ---
> builtin/init-db.c | 2 --
> refs/files-backend.c | 4 ++++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index 944ec77fe1..45bdea0589 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -226,8 +226,6 @@ static int create_default_files(const char *template_path,
> * We need to create a "refs" dir in any case so that older
> * versions of git can tell that this is a repository.
> */
> - safe_create_dir(git_path("refs"), 1);
> - adjust_shared_perm(git_path("refs"));
>
> if (refs_init_db(&err))
> die("failed to set up refs db: %s", err.buf);
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 0ea66a28b6..f49b6f2ab6 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -3158,6 +3158,10 @@ static int files_init_db(struct ref_store *ref_store, struct strbuf *err)
> files_downcast(ref_store, REF_STORE_WRITE, "init_db");
> struct strbuf sb = STRBUF_INIT;
>
> + files_ref_path(refs, &sb, "refs");
> + safe_create_dir(sb.buf, 1);
> + // XXX adjust_shared_perm ?I am not sure what's there to wonder about with the question mark.
If this step is meant to be a preparation before we actually allow a different backend to be used, shouldn't the updated and prepared code behave identically in externally visible ways?
Thanks.