Re: git fails to checkout SHA1 submodule in SHA256 repo with --depth=1

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Nov 14, 2025, 22:55 UTC
Message-ID: <b434bcb1-bf6e-4fe7-af2d-8c33348378fa@xiplink.com>
In-Reply-To: <a1c0440a6eef8f306f53793b2f96636945d4ced4.camel@suse.com>

On 2025-11-13 03:15, Martin Wilck wrote:

Show 47 quoted lines

> On Wed, 2025-11-12 at 23:37 +0000, brian m. carlson wrote:
>> On 2025-11-12 at 16:32:01, Junio C Hamano wrote:
>>> Martin Wilck <mwilck@suse.com> writes:
>>>
>>>>> Subject: Re: git fails to checkout SHA1 submodule in SHA256
>>>>> repo with --depth=1
>>>
>>> I think it is not supposed to work to mix repositories like this,
>>> regardless of any other option like --depth.  I think brian gave a
>>> response to that effect in a thread in the past few months.
>>>
>>>      ... goes and looks ...
>>>
>>> https://lore.kernel.org/git/aJ5gOPQ9oologqj-@fruit.crustytoothpaste.net/
>>> https://lore.kernel.org/git/aKPJNNWMW9gtueEK@fruit.crustytoothpaste.net/
>>
>> Yes, that isn't going to work and it never will unless we add some
>> extension mechanism for that purpose.  The repository in question is
>> corrupt.
> 
> Ok, thanks for the clarification.
> 
> Let me just explain the use case: The distribution ((open)SUSE) has
> switched to git for version control of its packages. We have chosen
> SHA256, because we'll need to support the distribution for many years
> to come, much longer than SHA1 is going to be considered good enough.
> 
> We can store the source code of the package e.g. in the form of
> tarballs (and we do). But it's convenient and efficient, and thus
> tempting for developers, to simply link to an existing repository
> hosting the sources, using a submodule. And upstream repos still use
> SHA1. This is what lead us to experiment with this sort of mixed
> repository.
> 
> I get it that the concept is flawed and unsupported. Up to now, that
> wasn't obvious to me.
> 
> So what we can do now is either keep storing tarballs, or wait until
> there's a full solution for migration between / interoperability of
> different hash algorithms, and until the source code repos we're
> interested in have been fully migrated to SHA256. In some special
> cases, where (open)SUSE owns the source repositories, we may be able to
> simply migrate to a SHA256 forge. We can also invent a "poor man's
> submodule" mechanism to link to sources on some external repository
> from ours [1].
> 
> Do you see any other approach that I'm overlooking?

Set up SHA256 mirrors of the SHA1 repos you want to track in submodules?

I'm assuming that it would be easy to keep such mirrors up to date. I'm not familiar enough with Brian's work to know if a SHA256 repo can have a SHA1 remote (which would mean that updates would just be a simple "git fetch origin"), but even if that's not possible I'm guessing that scripting some kind of regularly-run translation of new commits wouldn't be too hard.

(This feels similar to Git's early years, when people set up Git mirrors of repos that used other VCSes like subversion...)

That might also help encourage your upstreams to switch, if you can give them a ready-to-use SHA256 version of their repos.

M.