|
|
|
|
|
by mikepurvis
2 hours ago
|
|
It makes sense, similar to how blob storage is a natural fit for a nix cache, where you have a giant flat space of many hash-address immutable directories/archives. I think most of the pain documented in the article is just that git-the-implementation contains a lot of assumptions about it being a (local) filesystem that it is operating on, hence stuff like calling stat a ton of times, or doing the rename trick to get atomic behavior from a not-normally-atomic operation (updating a file in place). If it were possible to define a "backing storage" API layer within git, it might be possible to move all the filesystem/posix-centric stuff to the other side of it and leave behind an interface that maps quite nicely to blob storage. |
|