Also, I think you are onto something. Git remotes are mostly passive, where you have to pull to see whether there are any updates. There is no subscription model to get notified of changes. You have to actively pull to find out what is new.
You should try to make this as a standalone service, which works with Git remotes, not just a Git hosting party. Then locally, you can pull the repo/commits and check what has updated (diff) and inform subscribers accordingly.
I'm trying to validate whether there's any interest in something this, so I definitely cut a lot of corners (e.g. the app doesn't maintain a copy of the repository — it just uses the GitHub API). Also using GitHub in the name might not have been the best idea.. though! ;)
I agree with you regarding the usefulness of watching arbitrary repositories. There's already git-notifier [0] that does pretty much this, but you have to set it up for yourself and it has to be configured using a text file.
https://github.com/ianmiell/alert-on-change/blob/master/READ...
I write plugins for RpgMaker and a lot of the people who use them are regular users who don't know how to use GitHub. Some of them had asked for a way they could get notifications every time I update a plugin, this will be very useful for that.
Can I request a feature? Would be nice to have a way I could pass the repository and file names on the query string, so I can put a link where people only need to inform their email and submit to start receiving notifications for that.
The GitHub API allows up to 5,000 requests per hour. I currently poll once an hour, so there's a bit of headway. If that becomes a problem, I think I can always space out checks for less-active repositories (there's also the option of allowing users to authenticate with GitHub and use their own quota so they don't have to share it with anyone else).
Cheers
https://github.com/ianmiell/alert-on-change/blob/master/READ...
It's probably more suited for the programming types.
For example, you can do a 'raw' GitHub request to determine when a particular file has changed.
I definitely plan to add this if there's enough interest. There should be a link to a mailing list to be notified when that rolls around (http://eepurl.com/bILhR1).
Thanks for checking it out anyway! : )
It's slightly more convenient for me to get a notification than to periodically pull repositories and check them for changes, but I understand that might not be the case for everyone!
Hi there,
https://news.ycombinator.com/item?id=10690114 looks good, but didn't
get much attention. Would you care to repost it? You can do so
here: https://news.ycombinator.com/repost?id=10690114.
Please use the same account (krallin), title, and URL. When these match,
the software will give the repost an upvote from the mods, plus we'll
help make sure it doesn't get flagged.
This is part of an experiment in giving good HN submissions multiple
chances at the front page. If you have any questions, let us know. And
if you don't want these emails, sorry! Tell us and we won't do it again.
Thanks for posting good things to Hacker News,
DanielI think a resubmitted post gets a small karma bump (1 or 2 points) to help it. But after that it's up to the community to vote.
Re criteria for filtering stories: karma isn't a factor; past submissions are. A downside of the latter might be a rich-get-richer effect, but we mitigate that by looking for any earlier submission of the same story and picking that one instead. We don't advise about timing; in fact we randomize the process to reduce timing effects.
We mostly don't send repost invites anymore, but rather re-up the original post by rolling back its internal clock and giving it a random placement near the bottom of the front page. This guarantees a few minutes of community exposure, and regular upvoting decides the rest. On the front page, we display the re-upped timestamp, not the original timestamp, because otherwise it's confusing—only the re-upped time makes sense relative to the other stories on the page. But the original timestamp is available on most of the other pages that list the story, like /submitted and /from, and the discrepancy is temporary, since eventually the two timestamps converge.
The reason we switched from reposts to re-ups is that HN users are averse to duplication. I trust that the programmers among them hold their code to the same standard. We do still send emails when it seems important for the submitter to know that their story may still make the front page—mostly for Show HNs, like this one.
All of this is the latest in a series of experiments we've been running, whose goal is to fix the problem of good stories falling through the cracks on HN. Earlier posts about this, for anyone who wants more background:
https://news.ycombinator.com/item?id=10742610 (more recent, but might as well keep this list up to date)
https://news.ycombinator.com/item?id=10537417
https://news.ycombinator.com/item?id=10395389
https://news.ycombinator.com/item?id=9866140