From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT
Date: Thu, 30 Jan 2025 14:40:04 -0800 [thread overview]
Message-ID: <xmqqy0ys9b97.fsf@gitster.g> (raw)
In-Reply-To: <20250130-b4-pks-reinit-default-ref-format-v1-2-d2769ca01207@pks.im> (Patrick Steinhardt's message of "Thu, 30 Jan 2025 17:24:18 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> The GIT_DEFAULT_REF_FORMAT environment variable can be set to influence
> the default ref format that new repostiories shall be initialized with.
> While this is the expected behaviour when creating a new repository, it
> is not when reinitializing a repository: we should retain the ref format
> currently used by it in that case.
>
> This doesn't work correctly right now:
>
> $ git init --ref-format=files repo
> Initialized empty Git repository in /tmp/repo/.git/
> $ GIT_DEFAULT_REF_FORMAT=reftable git init repo
> fatal: could not open '/tmp/repo/.git/refs/heads' for writing: Is a directory
>
> Instead of retaining the current ref format, the reinitialization tries
> to reinitialize the repository with the different format. This action
> fails when git-init(1) tries to write the ".git/refs/heads" stub, which
> in the context of the reftable backend is always written as a file so
> that we can detect clients which inadvertently try to access the repo
> with the wrong ref format. Seems like the protection mechanism works for
> this case, as well.
Good finding. A plausible alternative behaviour could be to do the
backend migration when this is asked, and we might gain consensus to
do so in the (far) future, but I agree that it is a good direction
to go in the short term to match the behaviour of the code to the
documented expectation.
next prev parent reply other threads:[~2025-01-30 22:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-30 16:24 [PATCH 0/3] setup: fix reinit of repos with different formats Patrick Steinhardt
2025-01-30 16:24 ` [PATCH 1/3] t0001: remove duplicate test Patrick Steinhardt
2025-01-30 16:24 ` [PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT Patrick Steinhardt
2025-01-30 22:40 ` Junio C Hamano [this message]
2025-01-31 22:38 ` Junio C Hamano
2025-02-03 5:29 ` Patrick Steinhardt
2025-02-03 14:01 ` Junio C Hamano
2025-02-03 15:02 ` Patrick Steinhardt
2025-01-30 16:24 ` [PATCH 3/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_HASH Patrick Steinhardt
2025-01-31 22:40 ` Junio C Hamano
2025-01-30 23:58 ` [PATCH 0/3] setup: fix reinit of repos with different formats brian m. carlson
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=xmqqy0ys9b97.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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.