Hi brian, On Sat, 13 Mar 2021, brian m. carlson wrote: > On 2021-03-01 at 19:28:13, Johannes Schindelin wrote: > > 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. Hrm, that's a valid point. I just wish that we could make this more independent of servers. There _might_ be a way to work around the flaw you pointed out, e.g. adding the mappings from `.gitmodules` to the repository-local SHA-1 <-> SHA-256 mapping. But maybe somebody else can think of a better way? Ciao, Dscho
