3 ms·

I seriously doubt there's a single repo on the planet that averages hundreds of commits per minute. That's completely unmanageable for any number of reasons.

by xxpor 4y ago

chucknthem 4y ago
It wouldn't surprise me at all if some large repos at Google or Facebook now get to that many, it's easy to do once you have robots committing code (usually configuration changes).
sangnoir 4y ago
I didn't mean on average, but the build tool has to handle the worst case and I probably am understating the worst case. I'd bet there are a more than a few repos that do get (at least) hundreds of commits as a highwater mark. My guess is lots of engineers + mono-repo + looming code-freeze deadline can do that like clockwork. Edit: Robots too as sibling pointed out. A single human action may result in dozens of bot-generated commits
- xxpor 4y ago
  IMO there's almost never a good reason to have automated commits in repos outside of two cases: 1) Automated refactoring 2) Automated merges when CI passes Configs that can be generated should just be generated by the build. But that's a different topic
  - rrdharan 4y ago
    There are at least two other hugely important use cases you missed: - automatic security / vendoring updates (e.g. https://github.com/renovatebot/renovate https://github.com/renovatebot/renovate) - automated cross-repo syncs, e.g. Google has processes and tools that bidirectionally sync pieces of Google3 with GitHub repos
  - sangnoir 4y ago
    > IMO there's almost never a good reason to have automated commit This depends entirely on the quality of dev tools available. Also, commit =/= shipped code: you may have a automated commits and keep a human in the loop before shipping, by way of rejectable Pull-Request (or the proprietary equivalent). A simple library upgrade will result in a wave of commits/bot-authored PRs 1. Human makes a change to a core library, changing it from v1 to v2 2. Bot identifies all call-sites and refactors to v2-equivalent, creating 50 PRs for 50 different teams. One change, 51 commits.
kps 4y ago
According to [1], in 2015 Google averaged 25 commits per minute (250000/7/24/60). I can imagine hundreds per minute during Pacific working hours today. [1] https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
- xxpor 4y ago
  In the case of a monorepo, that's exactly the case why the build system shouldn't be overly complex. If you're expecting random people to make changes to your stuff, you shouldn't be burdening them with more complexity than necessary. The monorepo case is also a little bit outside what I was originally talking about. I was mostly refering to individual services/libraries/apps

I seriously doubt there's a single repo on the planet that averages hundreds of commits per minute. That's completely unmanageable for any number of reasons.

by xxpor 4y ago

I seriously doubt there's a single repo on the planet that averages hundreds of commits per minute. That's completely unmanageable for any number of reasons.

chucknthem 4y ago

It wouldn't surprise me at all if some large repos at Google or Facebook now get to that many, it's easy to do once you have robots committing code (usually configuration changes).

sangnoir 4y ago

I didn't mean on average, but the build tool has to handle the worst case and I probably am understating the worst case. I'd bet there are a more than a few repos that do get (at least) hundreds of commits as a highwater mark. My guess is lots of engineers + mono-repo + looming code-freeze deadline can do that like clockwork. Edit: Robots too as sibling pointed out. A single human action may result in dozens of bot-generated commits

xxpor 4y ago
IMO there's almost never a good reason to have automated commits in repos outside of two cases: 1) Automated refactoring 2) Automated merges when CI passes Configs that can be generated should just be generated by the build. But that's a different topic
- rrdharan 4y ago
  There are at least two other hugely important use cases you missed: - automatic security / vendoring updates (e.g. https://github.com/renovatebot/renovate https://github.com/renovatebot/renovate) - automated cross-repo syncs, e.g. Google has processes and tools that bidirectionally sync pieces of Google3 with GitHub repos
- sangnoir 4y ago
  > IMO there's almost never a good reason to have automated commit This depends entirely on the quality of dev tools available. Also, commit =/= shipped code: you may have a automated commits and keep a human in the loop before shipping, by way of rejectable Pull-Request (or the proprietary equivalent). A simple library upgrade will result in a wave of commits/bot-authored PRs 1. Human makes a change to a core library, changing it from v1 to v2 2. Bot identifies all call-sites and refactors to v2-equivalent, creating 50 PRs for 50 different teams. One change, 51 commits.

kps 4y ago

According to [1], in 2015 Google averaged 25 commits per minute (250000/7/24/60). I can imagine hundreds per minute during Pacific working hours today. [1] https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

xxpor 4y ago
In the case of a monorepo, that's exactly the case why the build system shouldn't be overly complex. If you're expecting random people to make changes to your stuff, you shouldn't be burdening them with more complexity than necessary. The monorepo case is also a little bit outside what I was originally talking about. I was mostly refering to individual services/libraries/apps