Re: Submodules and SHA-256/SHA-1 interoperability

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 13, 2021, 19:42 UTC
Message-ID: <YE0Vki0HNOYhYIYh@camp.crustytoothpaste.net>
In-Reply-To: <nycvar.QRO.7.76.6.2103011621000.57@tvgsbejvaqbjf.bet>

On 2021-03-01 at 19:28:13, Johannes Schindelin wrote:

Show 11 quoted lines

> While my strong urge is to add "Remove support for submodules" (which BTW
> would also plug so many attack vectors that have lead to many a
> vulnerability in the past), I understand that this would be impractical:
> the figurative barn door has been open for way too long to do that.
> 
> But I'd like to put another idea into the fray: store the mapping in
> `.gitmodules`. That is, each time `git submodule add <...>` is called, it
> would update `.gitmodules` to list SHA-1 *and* SHA-256 for the given path.
> 
> That would relieve us of the problem where we rely on a server's ability
> to give us that mapping.

This is true, but it ends up causing problems because we don't know where the .gitmodules file is for a given revision. If we're indexing a pack file, we lack the ability to know which .gitmodules file is associated with the blobs in a given revision, and we can't finish indexing that file until we have both hashes for every object.

While we could change the way we do indexing, we'd end up having to crawl the history and that would be very slow.

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US