Default object format for new repositories in Git v3

Default object format for new repositories in Git v3

[Adam Dinwoodie]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Hi folks,

As part of preparing for Git v3, in particular for Nixpkgs, I've been
running a bunch of tests using Git built with
`WITH_BREAKING_CHANGES=1`. Somewhat to my surprise, `git init` seems
to still be creating new repositories using sha1 rather than sha256.
Is this expected?

For reference, I've attached the test script I've produced as a repro
that can be run from the root of a Git checkout, although it does
require Nix. I've confirmed the behaviour at v2.56.0, next
(972d6e3ab651d838b30a8d5d70d8ef6ced05a986) and main
(0ffa3e35c7c82ab8d0de226149fb03b3f7674d05).

For a simpler repro that doesn't require Nix, build Git with
`WITH_BREAKING_CHANGES=1`, then run:

```
git init tmpdir
git -C tmpdir rev-parse --show-object-format
```

This will print "sha1", when I'd expect "sha256".

[-- Attachment #2: test.sh --]
[-- Type: text/x-sh, Size: 1832 bytes --]

#!/usr/bin/env nix
#!nix shell
#!nix --override-flake nixpkgs https://releases.nixos.org/nixos/unstable/nixos-26.11pre1105037.1c89083e451e/nixexprs.tar.zst
#!nix --ignore-env
#!nix nixpkgs#bash nixpkgs#coreutils nixpkgs#nix nixpkgs#findutils nixpkgs#gnused nixpkgs#autoconf nixpkgs#gnumake nixpkgs#gcc nixpkgs#cargo
#!nix --command bash

set -euo pipefail

tmpdir="$(mktemp --dir)"
trap 'rm -rf -- "$tmpdir"' EXIT

# Get the paths we need for zlib-ng
export NIX_PATH=nixpkgs=https://releases.nixos.org/nixos/unstable/nixos-26.11pre1105037.1c89083e451e/nixexprs.tar.zst
nix-build '<nixpkgs>' -A zlib-ng -A zlib-ng.dev -o "$tmpdir"/zlib-ng
zlib_lib="$(realpath "$tmpdir"/zlib-ng)"
zlib_dev="$(realpath "$tmpdir"/zlib-ng-dev)"

# Work out how much to parallelise the builds
jobs="$(nproc)"

# Make sure the build process can find zlib-ng
export CPPFLAGS="-isystem $zlib_dev/include" LDFLAGS="-L$zlib_lib/lib -Wl,-rpath,$zlib_lib"

# Set options: disable features we don't need for speed of building, use
# zlib-ng, enable breaking changes.
export ZLIB_NG=1 WITH_BREAKING_CHANGES=1 NO_TCLTK=1 NO_GETTEXT=1

# Build git
make -j"$jobs" configure
./configure
make -j"$jobs"

# Make sure Git config doesn't have anything unexpected
export GIT_CONFIG_GLOBAL=/dev/null
export GIT_CONFIG_SYSTEM=/dev/null
export GIT_CONFIG=/dev/null
export GIT_CONFIG_COUNT=2
export GIT_CONFIG_KEY_0=user.name GIT_CONFIG_VALUE_0=Adam
export GIT_CONFIG_KEY_1=user.email GIT_CONFIG_VALUE_1=adam@localhost
export GIT_PAGER=cat

# Make sure calling `git` gets the right executable
export PATH="$PWD":"$PATH"

# Set up a simple repository with a single commit
git init "$tmpdir"/repo
cd "$tmpdir"/repo
touch test-file
git add test-file
git commit -m 'demo commit'

# Show everything's sha1 rather than sha256
git log --format=raw
git rev-parse --show-object-format

Re: Default object format for new repositories in Git v3

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On 2026-11-06 at 16:50:03, Adam Dinwoodie wrote:
> Hi folks,
> 
> As part of preparing for Git v3, in particular for Nixpkgs, I've been
> running a bunch of tests using Git built with
> `WITH_BREAKING_CHANGES=1`. Somewhat to my surprise, `git init` seems
> to still be creating new repositories using sha1 rather than sha256.
> Is this expected?
> 
> For reference, I've attached the test script I've produced as a repro
> that can be run from the root of a Git checkout, although it does
> require Nix. I've confirmed the behaviour at v2.56.0, next
> (972d6e3ab651d838b30a8d5d70d8ef6ced05a986) and main
> (0ffa3e35c7c82ab8d0de226149fb03b3f7674d05).
> 
> For a simpler repro that doesn't require Nix, build Git with
> `WITH_BREAKING_CHANGES=1`, then run:
> 
> ```
> git init tmpdir
> git -C tmpdir rev-parse --show-object-format
> ```
> 
> This will print "sha1", when I'd expect "sha256".

This does appear to be broken.  I have a patch that should fix it that's
running through CI right now.  I'll send it once it's green, either
later tonight or tomorrow.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Speaking for myself only

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

[PATCH] setup: default hash algo to GIT_HASH_DEFAULT

[brian m. carlson]

When we have no other hash algorithm to choose, we set no hash
algorithm, which ends up with us defaulting to SHA-1.  Instead, default
to GIT_HASH_DEFAULT.  This means that we will choose SHA-256 in breaking
changes mode and in Git 3.0, which is what we want.

Reported-by: Adam Dinwoodie <adam@dinwoodie.org>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 setup.c         |  2 ++
 t/t0001-init.sh | 16 ++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/setup.c b/setup.c
index 61bcdafe82..4a0dfc8908 100644
--- a/setup.c
+++ b/setup.c
@@ -2830,6 +2830,8 @@ static void repository_format_configure(struct repository_format *repo_fmt,
 			repo_fmt->hash_algo = env_algo;
 	} else if (cfg.hash != GIT_HASH_UNKNOWN) {
 		repo_fmt->hash_algo = cfg.hash;
+	} else {
+		repo_fmt->hash_algo = GIT_HASH_DEFAULT;
 	}
 
 	/*
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index f1d227f271..98c7562f32 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -516,6 +516,22 @@ test_expect_success 're-init from a linked worktree' '
 	)
 '
 
+test_expect_success 'git init uses default object format' '
+	test_when_finished "rm -rf repo" &&
+	(
+		sane_unset GIT_DEFAULT_HASH &&
+		git init repo &&
+		if test_have_prereq WITH_BREAKING_CHANGES
+		then
+			echo sha256
+		else
+			echo sha1
+		fi >expect &&
+		git -C repo rev-parse --show-object-format >actual &&
+		test_cmp expect actual
+	)
+'
+
 test_expect_success 'init honors GIT_DEFAULT_HASH' '
 	test_when_finished "rm -rf sha1 sha256" &&
 	GIT_DEFAULT_HASH=sha1 git init sha1 &&

Re: [PATCH] setup: default hash algo to GIT_HASH_DEFAULT

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> When we have no other hash algorithm to choose, we set no hash
> algorithm, which ends up with us defaulting to SHA-1.  Instead, default
> to GIT_HASH_DEFAULT.  This means that we will choose SHA-256 in breaking
> changes mode and in Git 3.0, which is what we want.
>
> Reported-by: Adam Dinwoodie <adam@dinwoodie.org>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  setup.c         |  2 ++
>  t/t0001-init.sh | 16 ++++++++++++++++
>  2 files changed, 18 insertions(+)

With Git 3.0, we promised that SHA-1/SHA-256 interop will not have
to be ready, and that SHA-256 would become the default.  And this
patch would be a good thing to have for the second promise.

But didn't we also discuss "empty/initial repository whose hash
algorithm is undecided can take a push of either SHA-1 or SHA-256
payload and that first push can decide and freeze the hash algorithm
used in the repository" or something along that line?

I am wondering if we want to reserve 'HASH_UNKNOWN' for such a "was
just created, not quite finished initializing yet" state.

The patch looks good for the goal stated in the log message.

Thanks.




> diff --git a/setup.c b/setup.c
> index 61bcdafe82..4a0dfc8908 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -2830,6 +2830,8 @@ static void repository_format_configure(struct repository_format *repo_fmt,
>  			repo_fmt->hash_algo = env_algo;
>  	} else if (cfg.hash != GIT_HASH_UNKNOWN) {
>  		repo_fmt->hash_algo = cfg.hash;
> +	} else {
> +		repo_fmt->hash_algo = GIT_HASH_DEFAULT;
>  	}
>  
>  	/*
> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> index f1d227f271..98c7562f32 100755
> --- a/t/t0001-init.sh
> +++ b/t/t0001-init.sh
> @@ -516,6 +516,22 @@ test_expect_success 're-init from a linked worktree' '
>  	)
>  '
>  
> +test_expect_success 'git init uses default object format' '
> +	test_when_finished "rm -rf repo" &&
> +	(
> +		sane_unset GIT_DEFAULT_HASH &&
> +		git init repo &&
> +		if test_have_prereq WITH_BREAKING_CHANGES
> +		then
> +			echo sha256
> +		else
> +			echo sha1
> +		fi >expect &&
> +		git -C repo rev-parse --show-object-format >actual &&
> +		test_cmp expect actual
> +	)
> +'
> +
>  test_expect_success 'init honors GIT_DEFAULT_HASH' '
>  	test_when_finished "rm -rf sha1 sha256" &&
>  	GIT_DEFAULT_HASH=sha1 git init sha1 &&

Re: [PATCH] setup: default hash algo to GIT_HASH_DEFAULT

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

On 2026-11-08 at 04:42:56, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > When we have no other hash algorithm to choose, we set no hash
> > algorithm, which ends up with us defaulting to SHA-1.  Instead, default
> > to GIT_HASH_DEFAULT.  This means that we will choose SHA-256 in breaking
> > changes mode and in Git 3.0, which is what we want.
> >
> > Reported-by: Adam Dinwoodie <adam@dinwoodie.org>
> > Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> > ---
> >  setup.c         |  2 ++
> >  t/t0001-init.sh | 16 ++++++++++++++++
> >  2 files changed, 18 insertions(+)
> 
> With Git 3.0, we promised that SHA-1/SHA-256 interop will not have
> to be ready, and that SHA-256 would become the default.  And this
> patch would be a good thing to have for the second promise.
> 
> But didn't we also discuss "empty/initial repository whose hash
> algorithm is undecided can take a push of either SHA-1 or SHA-256
> payload and that first push can decide and freeze the hash algorithm
> used in the repository" or something along that line?

We discussed that as a possibility, but it requires protocol changes and
nobody has stepped up to implement that.  I think Peff was thinking
about maybe implementing that, but I don't think anyone came to a
decision.

> I am wondering if we want to reserve 'HASH_UNKNOWN' for such a "was
> just created, not quite finished initializing yet" state.

I think we concluded that we'd need to initialize a repository to _some_
hash algorithm even if we had the limbo state because otherwise people
could `git init` and then work locally and we need to have some existing
hash algorithm for that case.  That would be true even with bare
repositories.

So I think the limbo functionality, if we implemented it, would be a
separate option (maybe `extensions.potentialObjectFormat`?) and this
patch should go in either way.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Speaking for myself only

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: [PATCH] setup: default hash algo to GIT_HASH_DEFAULT

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> When we have no other hash algorithm to choose, we set no hash
> algorithm, which ends up with us defaulting to SHA-1.  Instead, default
> to GIT_HASH_DEFAULT.  This means that we will choose SHA-256 in breaking
> changes mode and in Git 3.0, which is what we want.
>
> Reported-by: Adam Dinwoodie <adam@dinwoodie.org>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  setup.c         |  2 ++
>  t/t0001-init.sh | 16 ++++++++++++++++
>  2 files changed, 18 insertions(+)
>
> diff --git a/setup.c b/setup.c
> index 61bcdafe82..4a0dfc8908 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -2830,6 +2830,8 @@ static void repository_format_configure(struct repository_format *repo_fmt,
>  			repo_fmt->hash_algo = env_algo;
>  	} else if (cfg.hash != GIT_HASH_UNKNOWN) {
>  		repo_fmt->hash_algo = cfg.hash;
> +	} else {
> +		repo_fmt->hash_algo = GIT_HASH_DEFAULT;
>  	}

Hmph, maybe I am not reading the code flow correctly, but does this
not break running "git init" to reinitialize an already initialized
repository?  I mimicked the new test in your patch and wrote the
following just immediately after it, which

 * figures out our hash and the other hash
 * create a new repository with the "other" hash
 * run "git init" without specifying any hash

It is debatable what should happen when you run "git init" from Git
3.0 without any specialization in an existing SHA-1 repository.

Possibilities include:

 1. turn an existing SHA-1 repository into SHA-256 including format
    conversion.

 2. notice that the repository is already set up to use the SHA-1
    format, and that the user did not explicitly say what format to
    use, and behave as if --object-format=sha1 were given with a
    notice or warning.

 3. notice that the repository is already set up to use the SHA-1
    format, but our default format is SHA-256.  Because the user did
    not countermand via an explicit --object-format=sha1 on the
    command line, we should fail loudly, "cannot convert this SHA-1
    repository to SHA-256".

I think #1 is impractical, #2 is probably the best, and #3 would
also be reasonable.

But the behaviour I am seeing with

    $ make WITH_BREAKING_CHANGES=YesPlease
    $ cd t && WITH_BREAKING_CHANGES=YesPlease sh t0001-init.sh -i -v

with the additional patch is different from any of the three (well,
technically, because the repository is empty, we _could_ argue that
we did #1, but ...).

I wonder what the "git init" command does wrt the reference storage
format (Patrick CC'ed for this)?  I am sure we do not convert from
reffiles to reftable on the fly at "git init" time.


diff --git i/t/t0001-init.sh w/t/t0001-init.sh
index bc30cf853b..1d48a712ae 100755
--- i/t/t0001-init.sh
+++ w/t/t0001-init.sh
@@ -532,6 +532,31 @@ test_expect_success 'git init uses default object format' '
 	)
 '
 
+test_expect_success 'git (re)init does not clobber object format' '
+	test_when_finished "rm -rf repo" &&
+	(
+		sane_unset GIT_DEFAULT_HASH &&
+		if test_have_prereq WITH_BREAKING_CHANGES
+		then
+			ours=sha256 opposite=sha1
+		else
+			ours=sha1 opposite=sha256
+		fi &&
+
+		# initialize to non-default format
+		git init --object-format=$opposite repo &&
+		git -C repo rev-parse --show-object-format >actual &&
+		echo "$opposite" >expect &&
+		test_cmp expect actual &&
+
+		# reinitialize without configuration
+		git init repo &&
+		git -C repo rev-parse --show-object-format >actual &&
+		echo "$opposite" >expect &&
+		test_cmp expect actual
+	)
+'
+
 test_expect_success 'init honors GIT_DEFAULT_HASH' '
 	test_when_finished "rm -rf sha1 sha256" &&
 	GIT_DEFAULT_HASH=sha1 git init sha1 &&

Re: [PATCH] setup: default hash algo to GIT_HASH_DEFAULT

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I wonder what the "git init" command does wrt the reference storage
> format (Patrick CC'ed for this)?  I am sure we do not convert from
> reffiles to reftable on the fly at "git init" time.

I looked at setup.c:repository_format_configure() and found why
your patch regresses, as well as a latent bug in the existing code.

First, REPOSITORY_FORMAT_INIT sets .hash_algo = GIT_HASH_DEFAULT,
but read_repository_format() forces it to GIT_HASH_SHA1_LEGACY
when version == -1 (no config yet), which is why new repositories
kept getting SHA-1.

Second, unlike the ref-storage block right below it, which checks
"else if (repo_fmt->version >= 0)" once between the explicit
overrides and all default sources, the hash-algo block guards only
the GIT_DEFAULT_HASH branch (repo_fmt->version < 0), leaving "else
if (cfg.hash != GIT_HASH_UNKNOWN)" unguarded.

So init.defaultObjectFormat in ~/.gitconfig already corrupts an
existing repository on re-init, and an unguarded "else" for
GIT_HASH_DEFAULT falls into the same trap even without config.

Instead of starting the if/else if cascade like this:

	if (repo_fmt->version >= 0 &&
	    hash != GIT_HASH_UNKNOWN &&
	    hash != repo_fmt->hash_algo)
		die(_("attempt to reinitialize repository with different hash"));

we should have started it like so:

	if (repo_fmt->version >= 0) {
		if (hash != GIT_HASH_UNKNOWN && hash != repo_fmt->hash_algo)
			die(_("attempt to reinitialize repository with different hash"));
		/* otherwise happy */
	} else if ...

so that all the "set a new value from different sources like command
line, environment, ~/.gitconfig, or the built-in default" would
happen only when (repo_fmt->version < 0), probably?

Re: [PATCH] setup: default hash algo to GIT_HASH_DEFAULT

[Patrick Steinhardt]

On Sun, Nov 08, 2026 at 06:21:43PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I wonder what the "git init" command does wrt the reference storage
> > format (Patrick CC'ed for this)?  I am sure we do not convert from
> > reffiles to reftable on the fly at "git init" time.

Yeah, we don't, and I don't think that would be reasonable. I would very
much be surprised if git-init(1) migrated a repository's hash format,
ref storage format or object storage format. Those are long-running
operations and in the past, git-init(1) used to be somewhat idempotent
on an already-initialized repository. So I'd much rather have us migrate
explicitly, like we do with `git refs migrate`.

> I looked at setup.c:repository_format_configure() and found why
> your patch regresses, as well as a latent bug in the existing code.
> 
> First, REPOSITORY_FORMAT_INIT sets .hash_algo = GIT_HASH_DEFAULT,
> but read_repository_format() forces it to GIT_HASH_SHA1_LEGACY
> when version == -1 (no config yet), which is why new repositories
> kept getting SHA-1.
> 
> Second, unlike the ref-storage block right below it, which checks
> "else if (repo_fmt->version >= 0)" once between the explicit
> overrides and all default sources, the hash-algo block guards only
> the GIT_DEFAULT_HASH branch (repo_fmt->version < 0), leaving "else
> if (cfg.hash != GIT_HASH_UNKNOWN)" unguarded.
> 
> So init.defaultObjectFormat in ~/.gitconfig already corrupts an
> existing repository on re-init, and an unguarded "else" for
> GIT_HASH_DEFAULT falls into the same trap even without config.
> 
> Instead of starting the if/else if cascade like this:
> 
> 	if (repo_fmt->version >= 0 &&
> 	    hash != GIT_HASH_UNKNOWN &&
> 	    hash != repo_fmt->hash_algo)
> 		die(_("attempt to reinitialize repository with different hash"));
> 
> we should have started it like so:
> 
> 	if (repo_fmt->version >= 0) {
> 		if (hash != GIT_HASH_UNKNOWN && hash != repo_fmt->hash_algo)
> 			die(_("attempt to reinitialize repository with different hash"));
> 		/* otherwise happy */
> 	} else if ...
> 
> so that all the "set a new value from different sources like command
> line, environment, ~/.gitconfig, or the built-in default" would
> happen only when (repo_fmt->version < 0), probably?

Yeah, these blocks are overall quite hard to read. That's also the
reason why I re-did these checks for both the ref storage format and
then also used the new style for the object storage format. So my take
is that we should adapt the object format in a similar fashion so that
all of them use the same style, where we first detect the desired format
and then check whether we're trying to re-initialize with a different
object format towards the end of this function.

So something like this:

diff --git a/setup.c b/setup.c
index 61bcdafe82a..bf75abafeeb 100644
--- a/setup.c
+++ b/setup.c
@@ -2816,20 +2816,19 @@ static void repository_format_configure(struct repository_format *repo_fmt,
 	 * specify a different algorithm, as that could cause corruption.
 	 * Otherwise, if the user has specified one on the command line, use it.
 	 */
-	env = getenv(GIT_DEFAULT_HASH_ENVIRONMENT);
-	if (repo_fmt->version >= 0 && hash != GIT_HASH_UNKNOWN && hash != repo_fmt->hash_algo)
-		die(_("attempt to reinitialize repository with different hash"));
-	else if (hash != GIT_HASH_UNKNOWN)
-		repo_fmt->hash_algo = hash;
-	else if (env) {
+	if (hash != GIT_HASH_UNKNOWN) {
+		/* nothing to do */
+	} else if ((env = getenv(GIT_DEFAULT_HASH_ENVIRONMENT))) {
 		int env_algo = hash_algo_by_name(env);
 		if (env_algo == GIT_HASH_UNKNOWN)
 			die(_("unknown hash algorithm '%s'"), env);
 		if (repo_fmt->version < 0 ||
 		    repo_fmt->hash_algo == GIT_HASH_UNKNOWN)
 			repo_fmt->hash_algo = env_algo;
-	} else if (cfg.hash != GIT_HASH_UNKNOWN) {
-		repo_fmt->hash_algo = cfg.hash;
+	} else if (repo_fmt->version >= 0) {
+		hash = repo_fmt->hash_algo;
+	} else {
+		hash = GIT_HASH_DEFAULT;
 	}
 
 	/*
@@ -2899,6 +2898,8 @@ static void repository_format_configure(struct repository_format *repo_fmt,
 	 * current ref storage format does not change.
 	 */
 	if (repo_fmt->version >= 0) {
+		if (hash != repo_fmt->hash_algo)
+			die(_("attempt to reinitialize repository with different hash"));
 		if (ref_storage_format != repo_fmt->ref_storage_format)
 			die(_("attempt to reinitialize repository with different reference storage format"));
 		if ((ref_storage_payload || repo_fmt->ref_storage_payload) &&

Patrick