setup: set repository's formats on init
commit58be32fff9d191ef8312a2c2c2f9deaf5d221c69
authorPatrick Steinhardt <ps@pks.im>
Fri, 29 Dec 2023 07:26:43 +0000 (29 08:26 +0100)
committerJunio C Hamano <gitster@pobox.com>
Tue, 2 Jan 2024 17:24:47 +0000 (2 09:24 -0800)
tree39bded86f8dbb84a6ef3c99e08fe135b5f2eb425
parent173761e21b2978fe7c0f7af7276e8b14511fed23
setup: set repository's formats on init

The proper hash algorithm and ref storage format that will be used for a
newly initialized repository will be figured out in `init_db()` via
`validate_hash_algorithm()` and `validate_ref_storage_format()`. Until
now though, we never set up the hash algorithm or ref storage format of
`the_repository` accordingly.

There are only two callsites of `init_db()`, one in git-init(1) and one
in git-clone(1). The former function doesn't care for the formats to be
set up properly because it never access the repository after calling the
function in the first place.

For git-clone(1) it's a different story though, as we call `init_db()`
before listing remote refs. While we do indeed have the wrong hash
function in `the_repository` when `init_db()` sets up a non-default
object format for the repository, it never mattered because we adjust
the hash after learning about the remote's hash function via the listed
refs.

So the current state is correct for the hash algo, but it's not for the
ref storage format because git-clone(1) wouldn't know to set it up
properly. But instead of adjusting only the `ref_storage_format`, set
both the hash algo and the ref storage format so that `the_repository`
is in the correct state when `init_db()` exits. This is fine as we will
adjust the hash later on anyway and makes it easier to reason about the
end state of `the_repository`.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup.c