{"thread":{"id":"65407","subject":"Cloning an empty SHA256 remote creates a local SHA1 repo","startedAt":"2026-04-01T10:51:54Z","lastAt":"2026-04-01T15:35:21Z","messageCount":3,"participants":["Miljan Mitrovic","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"540630","messageId":"DB4PR03MB101069CF70418ABE11AAC1CF3C850A@DB4PR03MB10106.eurprd03.prod.outlook.com","threadId":"65407","inReplyTo":null,"subject":"Cloning an empty SHA256 remote creates a local SHA1 repo","fromName":"Miljan Mitrovic","fromEmail":"mmitrovic@bentco.biz","sentAt":"2026-04-01T10:51:49Z","receivedAt":"2026-04-01T10:51:54Z","isPatch":false,"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\nCreated a blank remote SHA256 git repository, cloned that repository locally using git clone\n\nWhat did you expect to happen? (Expected behavior)\nI expected a warning I am cloning an empty repo but get a blank local SHA256 repository with remote set up.\n\nWhat happened instead? (Actual behavior)\nWarning 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.\n\nWhat's different between what you expected and what actually happened?\nI expected git clone to create the repo using the same hashing algorithm\n\nAnything 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.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.39.1.windows.1\ncpu: x86_64\nbuilt from commit: b03dafd9c26b06c92d509a07ab01b01e6d0d85ee\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Windows 10.0 26200\ncompiler info: gnuc: 12.2\nlibc info: no libc information available\n$SHELL (typically, interactive shell): \n"},{"id":"540639","messageId":"ac0TNM2l1r_cgwYj@pks.im","threadId":"65407","inReplyTo":"DB4PR03MB101069CF70418ABE11AAC1CF3C850A@DB4PR03MB10106.eurprd03.prod.outlook.com","subject":"Re: Cloning an empty SHA256 remote creates a local SHA1 repo","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-04-01T12:44:36Z","receivedAt":"2026-04-01T12:44:42Z","isPatch":false,"body":"Hi,\n\nOn Wed, Apr 01, 2026 at 10:51:49AM +0000, Miljan Mitrovic wrote:\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> Created a blank remote SHA256 git repository, cloned that repository locally using git clone\n> \n> What did you expect to happen? (Expected behavior)\n> I expected a warning I am cloning an empty repo but get a blank local SHA256 repository with remote set up.\n> \n> What happened instead? (Actual behavior)\n> 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.\n> \n> What's different between what you expected and what actually happened?\n> I expected git clone to create the repo using the same hashing algorithm\n> \n> 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.\n> \n> Please review the rest of the bug report below.\n> You can delete any lines you don't wish to share.\n\nThis was a known bug indeed, but we eventually fixed this by announcing\nan \"object-format\" capability that tells the client about the\nrepository's object format, even if it's empty.\n\n> [System Info]\n> git version:\n> git version 2.39.1.windows.1\n> cpu: x86_64\n> built from commit: b03dafd9c26b06c92d509a07ab01b01e6d0d85ee\n> sizeof-long: 4\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> feature: fsmonitor--daemon\n> uname: Windows 10.0 26200\n> compiler info: gnuc: 12.2\n> libc info: no libc information available\n> $SHELL (typically, interactive shell): \n\nThe fixes required for this have been released as part of Git v2.41. So\nonce you and your server run at least that version it should work as\nexpected.\n\nThanks!\n\nPatrick\n"},{"id":"540648","messageId":"DB4PR03MB101065ECA4EC20732CDD56747C850A@DB4PR03MB10106.eurprd03.prod.outlook.com","threadId":"65407","inReplyTo":"ac0TNM2l1r_cgwYj@pks.im","subject":"RE: Cloning an empty SHA256 remote creates a local SHA1 repo","fromName":"Miljan Mitrovic","fromEmail":"mmitrovic@bentco.biz","sentAt":"2026-04-01T15:35:17Z","receivedAt":"2026-04-01T15:35:21Z","isPatch":false,"body":"Ah gotcha. I just see that the client has not been auto-upgraded. \n\nI moved to 2.53 and now it works ok. \n\nThank you and apologies for the false alarm. \n\n/m\n\n-----Original Message-----\nFrom: Patrick Steinhardt \nSent: Wednesday, April 1, 2026 2:45 PM\nTo: Miljan Mitrovic \nCc: git@vger.kernel.org\nSubject: Re: Cloning an empty SHA256 remote creates a local SHA1 repo\n\n> 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.\n\nThe 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.\n\nThanks!\n\nPatrick\n"}]}