I don't have experience to know if that's cheaper (for the hoster) than just periodically calling the $(git fetch --mirror) endpoint. I could see opening a conversation with the major providers asking which they would prefer, since it's in everyone's best interest to not unduely hammer them
Excellent thank you. Those look like events on a specific resource rather than “firehose” which sounds more like a global events list. Everything GitHub has a quota so there’s no way companies are staying under the normal 5000 or 15000 limit to fetch all of the changes!
Based on my understanding, yes, the events are global and it is a firehose. The burden would be upon the consumer to drop messages not relevant to the repos it is watching, but almost certainly less heartache than trying to add individual subscriptions for thousands(?) of repos. The GitLab one seems less firehose-y but for this specific problem would still likely help not hammer them
To the best of my knowledge, any such quotas are per API key. It's possible they are per account, but creating accounts is free.
Also, any such mechanism would only be to advise the sync process that a commit (or push) had occurred, and it would still use the $(git fetch --mirror) process but would just be an optimization of not running it (all the time|too infrequently)
