anchor.diff:  * *"If I have an integration branch that comprises commits from different teams, it will be harder to rebase it on master"* - that is true, but it guarantees that when you do rebase over master, all the code is synced. With multiple repos, you get no such guarantee, and things will probably break after you rebase.
   * *"I don’t want to clone the entire product, it’s too big"* - cloning does not happen often. And if the Linux Kernel could be version controlled in a single repo, why do you need more?
   
  +## Interesting Examples
  +* http://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/[Google Is 2 Billion Lines of Code—And It’s All in One Place]
  +* http://blog.jupyter.org/2015/04/15/the-big-split/[Project Jupyter's "The Big Split"]
  +* https://github.com/torvalds/linux[Linux Kernel]
  +
  +
   ## Bottom Line
   
   If you are developing a single product, in which all components are tightly coupled and advance together, keep it simple and start out with a single repo. Each component can have its own subdirectory within that repo. The system wide build script/Makefile goes in the root of the repo. System tests get their own directory, and so does the shared APIs `proto` and `thrift` files.
  
positive.code: # The Dangers of Multirepo
  
  In this post I'm going to make the case for a somewhat unpopular opinion - using multiple git repos (AKA multirepo) is unnecessary and dangerous in many cases.
  
  ## The Story
  
  I've seen this happening multiple times: you and a few teammates are starting a new project. The project is some complicated system that is built out of several processes. You `git init` a new repo for each process without thinking about it too much, it feels natural. 
  
  As the system evolves, the processes start talking to each other over RPC, and since the processes use different programming languages, you use something like `protobuf` or `thrift`. You then find out that both the client, and the server are using the same `.proto` or `.thrift` files, so you create a new git repo and you stick the shared API stuff in it.
  
  Since you're a great programmer you always write unit tests for the component you're in charge of, and that fits snugly in your component's repo. A few weeks later, the system is a bit more mature and you want to start adding integration testing between components and system level testing to test the entire thing. But that doesn't really fit in any of the component's repos, and it's not really a shared-api thingy, so you create another repo for system testing.
  
  Later on you find out that two of the components can share some piece of infrastructure code, so you create a library out of it and put that in its own repo.
  
  Then you want some "magic script" to build your entire system from scratch and produce a shipable product, so you write it up. But where do you put it? Doesn't seem to fit in any of the repos we created... So let's create a new repo for build stuff.
  
  Without noticing, we've created ~10 git repositories for a single product. Welcome to MultiRepo Hell.
  
  While the above example sound extreme, I've actually seen this happen more than once. Let's examine why this is a terrible way to go.
  
  ## The Consequences
  
  There are quite a lot of consequences to going MultiRepo, so I'll try to keep each bullet short.
  
  .Versioning
  Since your processes depend on each other, you must have a way to specify which version of another process you support. This means that *every git repo must be versioned in a sensible way*. By sensible I mean that you should be able to specify a dependency on some feature, some bugfix, or some API version. This quickly becomes a headache as developers must keep updating their component's version. When they forget to do so, the entire system might be in an inconsistent state, where components do not agree on which version of some other component they want to use.
  
  .Build-Time Dependencies
  In many software projects (especially in C/C++) it is common to have multiple processes share code in the form of a library. This often means that you must build the librbary _before_ you build the dependent process (this is especially true when using static libraries). 
  
  .Run-Time Dependencies
  Assuming that your components are properly versioned, how do you make sure that the contents of your final package/ISO make sense? In other words, how can you tell that the dependencies between components make sense? For example, if componentA requires componentB-1.0 but componentC requires componentB-2.0, a possible consequence is an install time failure, or even worse - a run time failure.
  
  .Co-developing
  asdsad
  
  .Test Matrix
  jhll
  
  .Build Reproducability
  An important trait of a good build system is the ability to exactly reproduce a specific build from scratch. How would you do that in a multirepo system? The answer is that you need to know the exact state of each repo at the time the build was executed. That means that you need to track the exact commit SHA1s for each repository, and your  "magic script" now has to know how to check out the exact commit SHA1 for each repository and build it. If you haven't done that, you're in to some error-prone and tiring manual work to get each repo in to the specific commit.
  
  ## How does Sinlge Repo compare?
  Let's tackle each one of the above sections and see how simple it is when you're using a single git repository.
  
  .Versioning
  You don't need it. You have a single version, which represents the product's version, and that's it. Whenever you check out a commit, all sub-components are automatically aligned. It's like magic.
  
  .Build Time Dependencies
  The dependencies themselves still exist, but it's much easier to stay consistent. If a some commit changes the shared API, for example, it should also modify the dependent components to match that change. Everything stays consistent, and the changes across components are *atomic*.
  
  .Runtime Dependencies
  Similaraly to buildtime dependencies, runtime dependencies are a non issue in single repo. 
  
  .Co-developing
  Is as easy as working on a shared git branch. Just like git wants you to do. That branch contains the required changes across all components, and when it's merged - it's merged. There are no funky limbo states in which some components have merged their stuff and others haven't.
  
  .Test Matrix
  There is no test matrix. You simply test the latest version of your master branch. Easy breezy.
  
  .Relative Locations
  
  
  ## When can I use MultiRepo?
  MultiRepo is a suitable solution in some cases. Specifically, if you're developing loosly coupled components with stable APIs which maintain proper backwards compatibility, you might find that multirepo is a good solution for you. 
  Specifically, Micro Services architectures are probably better kept in many small repositories. 
  
  ## Counter Arguments
  Here are some common arguments that people have against using a single repo, and my thoughts on them:
  
negative.code: 
  So https://en.wikipedia.org/wiki/KISS_principle[KISS] and start out with a single repo. If you later feel you absolutely must break it into more than one repo - https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/[it's easy to do so].
  
  The main take away here is that using Multirepo does not come for free. There's a lot of overhead to maintaining multiple git repos, and you should avoid it if subdirectories within a single repo does the job for you.
  
  