Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Watch git repositories for changes #56

Open
pdaian opened this issue Jul 3, 2015 · 3 comments
Open

Watch git repositories for changes #56

pdaian opened this issue Jul 3, 2015 · 3 comments

Comments

@pdaian
Copy link

pdaian commented Jul 3, 2015

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
Copy link
Author

pdaian commented Jul 3, 2015

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
Copy link
Owner

cjb commented Jul 3, 2015

@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
Copy link
Author

pdaian commented Jul 3, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants