The problem is git enables many feature like shallow and parse cloning, packing specific object and data, getting specific files and git logs, etc. These are all battle tested on solid git server implementations. This is all not possible trying to reinvent a simplified git server with blossom.
Replies (5)
i'm definitely with you on that. i personally would even suggest to not even write one single bit of code that handles git. palm it off to Linus' excellent implementation and then see what it misses.
i always envisioned that nostr was just negotiation rendezvous easy inbound connection. i've already tried to work with an attempt to clone the core features of git, in pure Go, and it was endlessly problematic with even minimal lag between their work and what the git project has already progressed to.
git is just a unix shell protocol, based on stdio and unix filesystem. don't over think it. the protocol only needs to provide the correct references and paths.
also, it's just combinatorial stuff. you can't efficiently deal with multidimensional graphs, you want to stick with stuff that can be flattened into a 2d representation. branches and layers are basically exponentially more complex.
git is built on the directed acyclic graph geometry. there is a lot of shortcuts because you don't have to escape loops.
The reference implementation does exactly that. It uses nginx to pass request to the git-http-backend CGI scripts maintained by the git project.
I'm sure the midcurve meme apply here with 'just let git handle that'.
It turns out that the http wrapper (CGI scripts) is not that complicated. There are nearly 3 grasp implementations that do this bit internally. This enables shipping a single binary and handling the authorisation *before* the data is sent.
