Software Engineering at Google
Is the practice of shoving all disparate pieces of proprietary software (or individual projects) in the same repo a common occurrence?  I have found that pulling unrelated changes just so that I can push my changes is an inconvenience.  Furthermore, tracking the history of a particular project is confounded due to unrelated commits.  I am sure that their vcs (piper?) makes this a feasible task, but for git, it seems like it would suck.<p>The article posted by kyrra, mentions this.<p><i>Given the value gained from the existing tools Google has built and the many advantages of the monolithic codebase structure, it is clear that moving to more and smaller repositories would not make sense for Google&#x27;s main repository. The alternative of moving to Git or any other DVCS that would require repository splitting is not compelling for Google.</i><p>It seems like they have just too much invested in this &quot;shove it in the same repo&quot; style.  Or is this the more appropriate way to do things in a large organization?