Tags are just refs like any branch, so I don’t think either of these belong on a nostr relay at all. All got objects (commits, trees, blobs) and refs (heads/tags) should be stored like any got repository on a filesystem, that way all clients would be looking at the same remote repository data and all devs would be working on the same code base regardless of relays each contributor uses. Nostr events would describe things that don’t live on a hit repository such as pull requests, issues, comments etc. A repository event may exist in nostr but it should probably serve to only provide metadata about a remote repository (name, description, remote/git-server)
Discussion
Wow so many typos there, sorry 😂
I think git objects are for a different hosting system than we have here. Git is for working the files. Nostr is for sending the notes about them.
I think you're right on the money with putting the social side on Nostr being the best use.
However, git data itself is just text about the history of the repo. Commits over time. what the parents are, what I've changed. The data itself is also all text, or encoded data into text. Use of it is doing some work in a text editor and then recording that in git as checkpoint in time.
It seems to me you could export to a series of notes and also rebuild a git repo from these notes if they were all on the relay, to be found and parsed.
You certainly can, I’ve already done that (wrote a git-remote-helper which would create (or pull) events) these events where as you says the individual objects and refs of a repository, it works but it’s a very bad idea for many reasons. So although we can, we definitely do not want to store a repo with events.
Here’s a couple screenshots of a prototype I built around this a couple weeks ago. Getting repos pushing/pulling over nostr and storing the contents of the repo is not the problem, that was easy, the problems come when some events exist on relay and not another depending on collaborators relays when pushing, this could be solved by storing the relay to publish to along with the repository metadata but I wouldn’t want to rely on a relay storing each git object. Nostr for social side is the way to go, git server sending updates to nostr relays as and when things happen but not the git objects themselves. That was the output from my exploration.
Note in the screenshot before pushing anything to a repo the remote protocol (nostr://)
That sounds like you're allowing multiple collaborators to a single 'nostr' repo. Thats not likely a good idea on a public relay system. I was thinking a repo would belong a single identity. A 'nostr' repo for each identity involved as if each participant had their own 'public' hosted git remote repo, instead of collaborating together on a shared hosted repo.
It seems to me we would know if we constructed the notes correctly, if we lost one in the middle of the chain of commits, right? It should be pretty rare to lose a message when its broadcast to many relays. Git objects aren't appropriate because they're not chained. Everything would have to be in commit notes, with parents and timestamps. Git objects would be rebuilt as instructed by a series of patch contents in fully detailed commit notes.
Pretty sure we are both saying the same thing btw, although you can store the repo contents as events you really shouldn’t 👍🏽