Hacker News Reader

> Any operation over your repository that needs to be fast must be O(change) and not O(repo).

This is a good thought! It actually needs to be O(1/commit rate) though, so that having the monorepo doesn't create long queues of commits.

Or have some process batch passing ready to merge PRs into a combined PR and try to merge that. And best guess on the failing PR if it fails.

Just make presubmit a fraction of your postsubmit. Each change has fast operations while still having global testing.

Then if postsubmit fails you just have to rerun the intersection of failing tests and affected tests on each change since the last green commit.

If you go the batching route, bisection on failure makes it more like O(log(1/commit rate)).