But why do we need to be able to push 7600 commits per second to a single repo? Is this those monorepo people also wanting to have 100,000 agents writing to their one repo?
That seems to be the idea. Even big companies with a monorepo these numbers are insane.
I don’t get the value in capturing so much intermediate state saves as commits either. I understand the “atomic unit of work” idea, but it’s a bad idea masquerading as a good practice.
I use commits to document complete chunks of work I would realistically revert to — which means basically squashed PRs.
To merge 7000 PRs a second is a disaster that even with 100k employees you shouldn’t be able to hit, and your batched deploy pipeline will probably fall over.
I do get the parallel work streams being annoying, but worktrees are built into git now.
I have a python script and shell command to manage worktrees by branch name (it pulls the branch if changed upstream or new, save to a .worktrees folder, copies .env over and stuff like node deps, then it opens a named tmux session).
I type
worktree ~/code/repo branchand it sets up a whole environment unambiguously for that work, it’s ready to go in a couple seconds.