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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux