Re: Submodules and SHA-256/SHA-1 interoperability
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Mar 19, 2021, 14:23 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2103191521290.57@tvgsbejvaqbjf.bet>
- In-Reply-To
- <YE0Vki0HNOYhYIYh@camp.crustytoothpaste.net>
Hi brian,
On Sat, 13 Mar 2021, brian m. carlson wrote:
Show 21 quoted lines
> 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