I taught a bucket to speak Git
11–20 of 20 posts
Re: I taught a bucket to speak Git
#12Great work, though I wish some of this work could be upstreamed to Gitea instead?
Re: I taught a bucket to speak Git
#13Most of the pain here is the typical set of issues people run into trying to make S3 a filesystem as-is, common with S3FS-family approaches. ZeroFS ( https://github.com/Barre/zerofs ) is 9P/NFS/NBD over S3 on an LSM. Point stock go-git, or just /usr/bin/git, at a mount and skip the gymnastics. Rename is a metadata op in the keyspace, so you get it atomic on any S3, no Tigris-specific X-Tigris-Rename needed. Different…
Re: I taught a bucket to speak Git
#14This was really thought provoking — it made me realize that Git just happens to use a filesystem for persistence, but doesn’t necessarily have to. A POSIX filesystem might not even be the best way to store a git repo. Makes me wonder: what else could speak Git + POSIX? Redis? Postgres? IPFS is a fun one — it’s already content addressed.
Re: I taught a bucket to speak Git
#15Most of the pain here is the typical set of issues people run into trying to make S3 a filesystem as-is, common with S3FS-family approaches. ZeroFS ( https://github.com/Barre/zerofs ) is 9P/NFS/NBD over S3 on an LSM. Point stock go-git, or just /usr/bin/git, at a mount and skip the gymnastics. Rename is a metadata op in the keyspace, so you get it atomic on any S3, no Tigris-specific X-Tigris-Rename needed. Different…
Would probably be great to have ZeroFS backed PVs for the K8s folks :)
Re: I taught a bucket to speak Git
#16Most of the pain here is the typical set of issues people run into trying to make S3 a filesystem as-is, common with S3FS-family approaches. ZeroFS ( https://github.com/Barre/zerofs ) is 9P/NFS/NBD over S3 on an LSM. Point stock go-git, or just /usr/bin/git, at a mount and skip the gymnastics. Rename is a metadata op in the keyspace, so you get it atomic on any S3, no Tigris-specific X-Tigris-Rename needed. Different…
I wouldn’t call it gymnastics. The surprising part of the article was that Git itself is an object store that happens to use a filesystem for persistence, but an S3 bucket might actually be more suitable than a .git directory on POSIX.
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.
Re: I taught a bucket to speak Git
#17Not exactly the same thing, but along the same lines of "git and s3 are both object stores, why not use s3 as git storage?"
Re: I taught a bucket to speak Git
#18Re: I taught a bucket to speak Git
#19I did something similar, though a full reimplementation of a git and git-lfs library in Elixir. Still a work in progress though as the S3 backend isn't quite complete and there are performance problems doing some git things through S3. https://anvil.fangorn.io/fangorn/ex_git_objectstore The documentation isn't quite correct, but it's getting there
Re: I taught a bucket to speak Git
#20This was really thought provoking — it made me realize that Git just happens to use a filesystem for persistence, but doesn’t necessarily have to. A POSIX filesystem might not even be the best way to store a git repo. Makes me wonder: what else could speak Git + POSIX? Redis? Postgres? IPFS is a fun one — it’s already content addressed.