Open pdaian opened 9 years ago
Also related to this: if you are running multiple gittorrent instances with the same repo and key, and you announce a newer ref on one node, the other nodes "seeding" that repository should update their copies rather than requiring a git pull
followed by a daemon restart.
@pdaian Yeah! This is an important change. It sounds like there should be a single "gittorrentd" per user that knows about all of the registered repos, and updates them on new changes.
It's possible that git push
can be that interface for updating the repo list, where git-remote-gittorrent
starts up and sends some API call to the gittorrentd
with the new repo->sha1 mapping.
I definitely like that architecture. It could even be simpler for minimum functionality (my opinion). If gittorrentd
watches all the repos it's seeding for changes, both on disk and over the network, you could simply seed a local repository on your machine if you have push access (access to the key) and push to that repository. gittorrentd
would then detect and share the change over the network, and other instances would automatically update to the latest head.
I understand the appeal of pushing to gittorrent URI's for a complete system though (without requiring a full local instance of the latest copy of the repo), and it would also cleanly solve #3.
So it seems that I have to restart gittorrentd after modifying the master of any repositories I'm hosting (either that or any update is really slow). This is not ideal, as I would like to have my developers push to a copy of the repo being watched by gittorrent, with gittorrent being notified of such a change and immediately updating the DHT / hosting the new master ref.
Perhaps this could be accomplished through a Git post-receive hook with a documented example? I'm restarting the daemon in a post-receive hook now as a temporary fix.