And you are here why?

/via http://www.commitstrip.com/en/2017/12/19/no-git-blame/ You’ve probably all done the “ git blame ” thing at some point or the other, right? You know, the one that goes something like 1. Spend a few hours tracking down a bug 2. Discover code that is … “interesting” 3. “Interesting” rapidly turns into “ WhatTF  is  this? ” 4. “ git blame ”, followed by “LOL,  of course  the code was written by Bob” 5. Hilarity ensues as you (and your buddies) laugh at Bob Now think of your postmortems. If you’re doing them — and I hope you are! — you’re probably striving for  blameless postmortems . As  The SRE Book puts it A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had. If a culture of finger pointing and shaming individuals or teams for doing the “wrong” thing prevails, people will not bring issues to light for fear of punishment. … When post...

(aka: “The use-case matters”) If you have a clear fit to one of the extremes, — “Loosely coupled highly distributed teams with well documented APIs”, or “Small local project with no dependencies, that only I work on”, for example, then hey, the choice is easy. Otherwise, it really really depends on your use case, because, there really is no “best of both worlds” option. For every broken dependency that your Monorepo prevents, you have library management and versioning issues that multirepo prevent Peter describes it best as “You could certainly tool up around a multirepo to make multiple repos act more like a single monorepo … establish a consistent toolchain, etc. across all repos to reduce the costs of making changes in other repos. But at that point its not clear what benefit you are getting from multiple repos unless there are other reasons to have some code in separate repos.” “ Or, in a monorepo, you could use branches to mimic the local stability you get in a multire...

via XKCD