Cloning an empty SHA256 remote creates a local SHA1 repo

Cloning an empty SHA256 remote creates a local SHA1 repo

[Miljan Mitrovic]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
Created a blank remote SHA256 git repository, cloned that repository locally using git clone

What did you expect to happen? (Expected behavior)
I expected a warning I am cloning an empty repo but get a blank local SHA256 repository with remote set up.

What happened instead? (Actual behavior)
Warning was there but the created local repo is SHA1. Commits then made to it are rejected by remote. And there is no method to convert a repo from SHA1 to SHA256, even when its blank.

What's different between what you expected and what actually happened?
I expected git clone to create the repo using the same hashing algorithm

Anything else you want to add: I know this is a fringe scenario, but it should work as expected. Now that repo's have roadblocking init settings, the important ones should be passed on to clone.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.39.1.windows.1
cpu: x86_64
built from commit: b03dafd9c26b06c92d509a07ab01b01e6d0d85ee
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 26200
compiler info: gnuc: 12.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>

Re: Cloning an empty SHA256 remote creates a local SHA1 repo

[Patrick Steinhardt]

Hi,

On Wed, Apr 01, 2026 at 10:51:49AM +0000, Miljan Mitrovic wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> 
> What did you do before the bug happened? (Steps to reproduce your issue)
> Created a blank remote SHA256 git repository, cloned that repository locally using git clone
> 
> What did you expect to happen? (Expected behavior)
> I expected a warning I am cloning an empty repo but get a blank local SHA256 repository with remote set up.
> 
> What happened instead? (Actual behavior)
> Warning was there but the created local repo is SHA1. Commits then made to it are rejected by remote. And there is no method to convert a repo from SHA1 to SHA256, even when its blank.
> 
> What's different between what you expected and what actually happened?
> I expected git clone to create the repo using the same hashing algorithm
> 
> Anything else you want to add: I know this is a fringe scenario, but it should work as expected. Now that repo's have roadblocking init settings, the important ones should be passed on to clone.
> 
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.

This was a known bug indeed, but we eventually fixed this by announcing
an "object-format" capability that tells the client about the
repository's object format, even if it's empty.

> [System Info]
> git version:
> git version 2.39.1.windows.1
> cpu: x86_64
> built from commit: b03dafd9c26b06c92d509a07ab01b01e6d0d85ee
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Windows 10.0 26200
> compiler info: gnuc: 12.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): <unset>

The fixes required for this have been released as part of Git v2.41. So
once you and your server run at least that version it should work as
expected.

Thanks!

Patrick

RE: Cloning an empty SHA256 remote creates a local SHA1 repo

[Miljan Mitrovic]

Ah gotcha. I just see that the client has not been auto-upgraded. 

I moved to 2.53 and now it works ok. 

Thank you and apologies for the false alarm. 

/m

-----Original Message-----
From: Patrick Steinhardt <ps@pks.im> 
Sent: Wednesday, April 1, 2026 2:45 PM
To: Miljan Mitrovic <mmitrovic@bentco.biz>
Cc: git@vger.kernel.org
Subject: Re: Cloning an empty SHA256 remote creates a local SHA1 repo

> This was a known bug indeed, but we eventually fixed this by announcing an "object-format" capability that tells the client about the repository's object format, even if it's empty.

The fixes required for this have been released as part of Git v2.41. So once you and your server run at least that version it should work as expected.

Thanks!

Patrick