Very useful! 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…
Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
21–30 of 30 posts
Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#22Very useful! 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…
Ha, this is a great idea! I've added this now :). Just reload.
Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#23What about you know… using Git?
Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#24Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#25Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#26Does not wok on private repo.
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! : )
Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#27Funny thing i almost did exactly this until i realized you can use rss which can also watch directories easily enough for example https://github.com/torvalds/linux/commits/master/Documentati... . Also unfortunately i found that using the api is probably not going to scale if a lot of people want to use it and local clones are pretty expensive.
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
Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#28Earlier quoted context omitted.
Yes, on HN reposts do not count as a dupe if the story hasn't had significant attention yet. In fact we invited the submitter to repost this one, which we sometimes do when a story seems like it would interest the community and deserves a second chance at attention.
Out of curiosity, when you ask someone to resubmit do you email them or is there some on-site messaging mechanism?
Re: Show HN: GitHub File Watcher – get notified when files change in a GitHub repo
#29Earlier quoted context omitted.
Yes, on HN reposts do not count as a dupe if the story hasn't had significant attention yet. In fact we invited the submitter to repost this one, which we sometimes do when a story seems like it would interest the community and deserves a second chance at attention.
Hmm, so I guess there's some sort of manual curation going on for what's interesting and can be posted again? Is there a criteria for such curation? Karma? Past posts? Past comments? Social influence? Who the OP really is? Will the OP also be advised on a better timing to post the link again so that it would have a better chance of getting attention?
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