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

From: Martin Wilck <mwilck@suse.com>
Date: Nov 13, 2025, 10:15 UTC
Message-ID: <a1c0440a6eef8f306f53793b2f96636945d4ced4.camel@suse.com>
In-Reply-To: <aRUaR6IfH9imrF5A@fruit.crustytoothpaste.net>

On Wed, 2025-11-12 at 23:37 +0000, brian m. carlson wrote:

Show 18 quoted lines

> 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?

Another question: If I, in the current repo [2], create a commit on top removing the submodule and replacing it by a tarball, would the repository remain broken, as it would still have the deprecated SHA256/SHA1 combination in the history? Should I expect errors if run e.g. "git rebase" or "git bisect" in a repository like this? IOW, do I need to rewrite the history of this repo, eliminating all instances of such mixed-hash submodules, to be on the safe side?

Thanks, Martin

[1] Such a thing exists already, but to me it feels less clean and elegant than using native git functionality. [2] https://src.opensuse.org/mwilck/multipath-tools