3 ms·

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 re

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.