cjb / GitTorrent

A decentralization of GitHub using BitTorrent and Bitcoin
MIT License
4.75k stars 262 forks source link

Watch git repositories for changes #56

Open pdaian opened 9 years ago

pdaian commented 9 years ago

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.

pdaian commented 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.

cjb commented 9 years ago

@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.

pdaian commented 9 years ago

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.