Unfortunately, I've been the dogmatic person in a lot of cases. Often the feel good viewpoint is just clueless and going to lead the company into real problems.

Unfortunately, I've been the dogmatic person in a lot of cases. Often the feel good viewpoint is just clueless and going to lead the company into real problems. I was recently at a company that was working on a custom AOSP build. Their engineers had no clue what the repo tool used to download AOSP source was and every day started arguments about how they wanted to replace it with git submodules and things like that. Generally so they could do something the repo tool already did, but they just didn't know how to do using it, such as documenting the sha1 commit hashes used for a particular build. If they had tons of engineers, fine, start rewriting core tooling, but it just made no sense at all for a small startup with strong time pressures for shipping and few engineers. Every other company from Google to drivers to system on a chip companies is using repo so making their own incompatible submodule based method would have 1) taken them a long time to reconfigure ~60GB of source code into a different format 2) made it really tough to bring in later changes from the old format 3) made it really tough to do things like integrate drivers and other code which typically ship with a README for how to integrate into AOSP repo manifests. Most of the people pushing the submodule rewrite had never even managed to build AOSP using repo in the first place, so their estimates and explanations usually made no sense. Yeah, it would have been the feel good solution to let them stupidly make their attempt and fail or waste a month of time, but that's going to hurt the company too, isn't it?