Additional background: The API we’ve been using to track “all commits” is github’s events api. The documentation for this now (I mean, since sometime between 2012ish and now) that says it should not be expected to act as a realtime endpoint, and could have delays of up to 6 hours. This spells bad news for edgeskating Beeminders relying on it.
So for the time being we’ve removed the “all commits” option, and we’re looking into possible mitigations or alternatives. Two ideas:
use the graphQL api to count up all a user’s commits across repos they participate in.
extend the existing api for single repo to allow you to add & track multiple (specific) repos on one Beeminder goal.
The former approach would presumably result in functionality pretty similar to the former all-commits minding behavior. However, it’s possible that it might not be practical in reality? I haven’t yet looked into how github’s graphql api handles ratelimiting and such, but it’s conceivable that if every time we ran this query it had to look through every repo a person’s ever committed to, it might be costly?
The latter would involve things that would probably make the integration for single repos more desirable/functional anyway, like adding specific branch support (instead of “only the main branch”), and settings for removing or adding repos to the goal. But it would require more active fiddling from the user, requiring you to add new branches or repositories as you started working on them. And it could still run into a similar problem with costly (in terms of our rate limits) queries of many many repos, though probably we could cross that bridge when we come to it?