From: Junio C Hamano <gitster@pobox•com>
To: "brian m. carlson" <sandals@crustytoothpaste•net>
Cc: git@vger•kernel.org, Patrick Steinhardt <ps@pks•im>
Subject: Re: [PATCH 05/10] setup: use the default algorithm to initialize repo format
Date: Fri, 20 Jun 2025 14:05:43 -0700 [thread overview]
Message-ID: <xmqqqzze15ug.fsf@gitster.g> (raw)
In-Reply-To: <aFXEgLRLRdbaPOb2@fruit.crustytoothpaste.net> (brian m. carlson's message of "Fri, 20 Jun 2025 20:28:48 +0000")
"brian m. carlson" <sandals@crustytoothpaste•net> writes:
>> > - if (format->version == -1)
>> > + if (format->version == -1) {
>>
>> And if there is no core.repositoryformatversion set, we will come
>> here. According to the comment before handle_extension_v0(), some
>> extensions.* should still be honored even in such a repository, and
>> the above call to git_config_from_file() should have handled them
>> just fine.
>>
>> However, I do not understand why we clear all of what we read with
>> another call to clear_repository_format() here.
>
> Because this is the case where there's no config file.
But my worries come from that .version == -1 does not necessarily
mean a missing config. Missing config will give .version == -1 but
the opposite may not be true, no?
> If nobody
> bothered to write a configuration file, then we want to reset everything
> to the default.
True. If config file is missing, yes, .version will be -1 and
clearing may make sense. But if the file is missing, we wouldn't
have anything to "reset to the default" because we wouldn't have
read anything, so what clear_repository_format() call initialized to
the default before we read config from file would still be there,
no?
> I don't know what we do if we have a repository with a config file and
> no version, but literally every repository since Git 0.99.3 (I believe)
> has core.repositoryformatversion written into the repo. I'm certain
> that the behaviour we'd want if nobody specified one was to do the most
> compatible thing, so the defaults seem prudent.
If our assumption is that no config file in repositories we care
about should lack core.repositoryformatversion, then what you wrote
above makes perfect sense, but then we should probably update the
comment before the handle_extension_v0() because it is stale. The
new semantics is that any extension.* found in a config file that
lacks core.repositoryformatversion will be ignored with the new
code, right? If that is our intention, it should be documented.
The current code will not clear, so there is a change in behaviour.
I do not know if we particularly care about this behaviour change,
though.
> The reason we need to read all the extensions is that different config
> options aren't ordered ...
Yes, that is where my "somewhat questionable" comes from. We'd have
to read everything in and then refrain from touching a repository
with extensions that should not exist (i.e., the ones we do not
understand, or the ones that should not be used with the stated
format version) in verify_repository_format() as you said.
Thanks.
next prev parent reply other threads:[~2025-06-20 21:05 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 1:19 [PATCH 00/10] Add SHA-256 by default as a breaking change brian m. carlson
2025-06-20 1:19 ` [PATCH 01/10] hash: add a constant for the default hash algorithm brian m. carlson
2025-06-20 1:19 ` [PATCH 02/10] hash: add a constant for the original " brian m. carlson
2025-06-20 1:56 ` Junio C Hamano
2025-06-20 20:43 ` brian m. carlson
2025-07-01 11:35 ` Patrick Steinhardt
2025-06-20 1:19 ` [PATCH 03/10] builtin: use default hash when outside a repository brian m. carlson
2025-06-20 14:19 ` Junio C Hamano
2025-07-01 11:35 ` Patrick Steinhardt
2025-07-01 21:14 ` brian m. carlson
2025-07-02 15:08 ` Patrick Steinhardt
2025-06-20 1:19 ` [PATCH 04/10] Use original hash for legacy formats brian m. carlson
2025-06-20 14:26 ` Junio C Hamano
2025-06-20 20:51 ` brian m. carlson
2025-06-20 21:14 ` Junio C Hamano
2025-07-01 11:35 ` Patrick Steinhardt
2025-06-20 1:19 ` [PATCH 05/10] setup: use the default algorithm to initialize repo format brian m. carlson
2025-06-20 14:55 ` Junio C Hamano
2025-06-20 20:28 ` brian m. carlson
2025-06-20 21:05 ` Junio C Hamano [this message]
2025-06-20 1:19 ` [PATCH 06/10] t: default to compile-time default hash if not set brian m. carlson
2025-06-20 1:19 ` [PATCH 07/10] t1007: choose the built-in hash outside of a repo brian m. carlson
2025-06-20 1:19 ` [PATCH 08/10] t4042: " brian m. carlson
2025-06-20 1:19 ` [PATCH 09/10] t5300: " brian m. carlson
2025-06-20 1:19 ` [PATCH 10/10] Enable SHA-256 by default in breaking changes mode brian m. carlson
2025-06-20 14:58 ` Junio C Hamano
2025-06-20 19:18 ` brian m. carlson
2025-06-20 15:03 ` Junio C Hamano
2025-06-20 19:15 ` brian m. carlson
2025-06-20 20:42 ` Junio C Hamano
2025-06-20 21:06 ` brian m. carlson
2025-07-01 11:35 ` Patrick Steinhardt
2025-07-01 21:22 ` [PATCH v2 00/11] Add SHA-256 by default as a breaking change brian m. carlson
2025-07-01 21:22 ` [PATCH v2 01/11] hash: add a constant for the default hash algorithm brian m. carlson
2025-07-01 21:22 ` [PATCH v2 02/11] hash: add a constant for the legacy " brian m. carlson
2025-07-01 21:22 ` [PATCH v2 03/11] builtin: use default hash when outside a repository brian m. carlson
2025-07-01 21:22 ` [PATCH v2 04/11] Use legacy hash for legacy formats brian m. carlson
2025-07-01 21:22 ` [PATCH v2 05/11] setup: use the default algorithm to initialize repo format brian m. carlson
2025-07-01 21:22 ` [PATCH v2 06/11] t: default to compile-time default hash if not set brian m. carlson
2025-07-01 21:22 ` [PATCH v2 07/11] t1007: choose the built-in hash outside of a repo brian m. carlson
2025-07-01 21:22 ` [PATCH v2 08/11] t4042: " brian m. carlson
2025-07-01 21:22 ` [PATCH v2 09/11] t5300: " brian m. carlson
2025-07-01 21:22 ` [PATCH v2 10/11] help: add a build option for default hash brian m. carlson
2025-07-01 21:22 ` [PATCH v2 11/11] Enable SHA-256 by default in breaking changes mode brian m. carlson
2025-07-01 22:10 ` [PATCH v2 00/11] Add SHA-256 by default as a breaking change Junio C Hamano
2025-07-02 14:46 ` Patrick Steinhardt
2025-07-02 15:01 ` Kristoffer Haugsbakk
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=xmqqqzze15ug.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=ps@pks$(echo .)im \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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