Traceability, simplicity, all sorts of reasons.

If you commit all your codegen’d stuff you don’t need to worry about how to run codegen in most places. You can enforce a lot of security properties, you can run large scale analysis on the code in production because it’s all “statically” available, etc.

That said, I think Google’s source control ecosystem is really quite different to what’s publicly available with systems like Git/Hub/Lab etc, even to Phabricator. These approaches work well at Google but don’t necessarily translate to other tools in the same way.

Don’t take these sorts of things as gospel, or even as google advice about good engineering. Understand what they achieve, and then figure out a way to achieve that same result with the tools available to you.

Theory: it makes secure builds that much more straightforward. You can just point goma at a repo and whatever it inhales is everything needed. The simplicity cascades downwards.

For example, "everything comes from a repo" would make object (.o) caching that much more straightforward.

And you can reason both about the logic behind a service and how it was configured from a single commit hash/CL.

Pure speculation on my part, but I've noticed Go has generate and build as separate steps and it's standard to check in generated code. This split no doubt makes compilation a lot simpler/faster, but perhaps it's a reflection of standard practices the language authors were used to.

Most of them are generated on the fly, like protos.

But you know, there are tons of configs, all kinds of.