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

[Patrick Steinhardt <ps@pks.im>]

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