

The bit about “comparability”. Where do you see that they will? (I mean, aside from the original article that claimed it without evidence.)
A submodule is “just” a pointer to a specific commit in an external repo. It was at one point entirely done via shell scripts, and unless I missed an update is still obnoxiously slow compared to the rest of git.
I can’t fathom why the SHA-256 support for submodules would do more than just treat the SHA as a foreign key.and go from there. We’d potentially be in trouble if SHA-1 support is being removed, but I don’t see any reason why git would do something so stupid.
(I honestly can’t fathom why SHA-256 hashed commits couldn’t be the children of SHA-1 commits. A bunch of reasons why you may not WANT to, but that’s a separate concern that seems like it’d be outweighed by comparability.)





Sorry for the late reply.
Again, do you have any actual evidence that SHA-256 repositories in version 3.0 won’t be able to reference SHA-1 repositories as submodules?
Based on the design doc it looks like git will include both hashes during the transition, specifically to allow two-way communication with SHA-1 remotes. You may not be able to include a random stranger’s SHA-1 submodule via a shallow clone, but just doing a full clone sure as heck looks like a supported usage.
https://git-scm.com/docs/hash-function-transition