Re: [PATCH] submodule: truncate the oid when fetchig commits

[Michael Schroeder <mls@suse.de>]

On Thu, Aug 14, 2025 at 10:16:24PM +0000, brian m. carlson wrote:
> On 2025-08-14 at 15:06:32, Michael Schroeder wrote:
> > If a submodule uses a different hash algorithm than used in
> > the main repository, the recorded submodule commit is padded
> > with zeros. This is usually not a problem as the default is to
> > do submodule clones non-shallow and the commit can be found
> > in the local objects.
> 
> This should not even work at all.  It may currently behave as you
> suggest when the main repository is SHA-256 and the submodule is SHA-1,
> but it will corrupt the data if the submodule is SHA-256 and the main
> repository is SHA-1, since then the data will be truncated.

But it works, and I'm pretty sure people already use it. If you
have a sha1 main repo and a sha256 submodule, git will truncate
the commit when recording the gitlink. The checkout done by
git submodule update will work as it does the normal prefix matching.

If you have a sha256 main repo and a sha submodule, the recorded
commit is padded with zero. The checkout will also work as git
ignores the extra data since commit 52fca06db2 (object-names: support
input of oids in any supported hash, 2023-10-01).

What doesn't work is if a shallow clone is done for the submodule.
In that case the commit is not reachable and git tries a direct
fetch. This fetch can be made to work if the commit was padded with
zeros. If the commit was truncated, we would probably need some
protocol extension to make the server do a prefix match for a
"want" request.

> The proper way for this to work is that the SHA-1 version of the
> repository stores submodules in their SHA-1 states and the SHA-256
> version of the repository stores submodules in their SHA-256 states.

You mean by using "compatObjectFormat"? I couldn't make that work,
but maybe I missed something. Anyway, I think this also will not
work for shallow clones.

Cheers,
  Michael.

-- 
Michael Schroeder          SUSE Software Solutions Germany GmbH
mls@suse.de               GF: Ivo Totev HRB 36809, AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}