It is my view that both our team and our codebase is "small", and that merging all git repos into one could be advantageous.  Note that i am exclusively talking about the git level, and not suggesting the merging of any Maven projects.  Maintaining a rigorous Maven structure is what would, in my opinion, allow us to do this with little risk or drawbacks.  In the following document, i will try to analyze the change in-depth.

Benefits
--------
- Much easier to add a new component (or remove a dead one)
  - Old procedure :
    - Commit in gitolite repo to create it (needs admin)
    - Create new repo in Phab (needs admin)
    - Create redundant .gitignore and .arcconfig, etc.
    - Initial commit in the new component
    - Another commit in gitolite repo to lock the master branch (needs admin)
  - New procedure :
    - mkdir `component`


- Code freezing
  - Can now be done in one commit instead of a dozen, making it easier to see all in one place that all versions are consistent and minimize errors
  - A single git log command can create a list of all changes present in a given release which can be useful both internally and externally
  - A "code freeze" can now have its own version which represent a complete snapshot of mercury, and represents what is deployed on production, with no uncertainty.  It would be more reliable than using a phabricator page.


- Committing
  - A feature will now have all of its component modifications in a single differential on Phab
    - Gives a better picture of the complete feature by seeing how all the parts work together (no more "config changes" commits whose purpose isn't always obvious)
    - This reduces potential errors, such as having half of a feature landed and the other half still under review at the time of a code freeze
    - Prevents one requested change in one repo to ripple through the other commits for that feature (perhaps after those dependant commits were approved and/or landed), requiring a whole new set of updates for the one change.


- Builds
  - We could have a "master pom" that serves to build all components, and lives in the top level repo.  This could allow us to easily schedule nightly builds of "mercury" as a whole.


- Deploying
  - It would be simple to make a python script that checks out the "code-freeze version" of the master repo, and deploys all proper versions to the proper nodes.  Since the code freeze version has been code reviewed, we can count on this to be reliable.  This deploy script will also be source-controlled and code reviewed, so we can be sure that its mapping of which component belongs on which node will always be accurate.  This will minimize human errors such as
    - forgetting to deploy one component
    - deploying a component to the wrong node
    - deploying the wrong version of a component


Drawbacks
---------
- Some of our components are publicly available and on GitHub.  These could probably not be part of the master mercury repository, but they are small in numbers, and can't be seen as third party libraries, made by us.  It's fairly harmless to have them out of the master repo as they almost never change anyway.
- Some commits may become larger since they'll sometimes affect more components; developers should strive to limit their size by breaking up the feature into smaller parts whenever possible.
- Performance.  Git may be a bit slower, but i'm not sure this is very meaningful for our small codebase.  [Google limits to 4GB for a repo](http://code.google.com/p/support/wiki/GitFAQ).  Mercury is <800MB with core, and < 300MB without core. Of course, our team and codebase will grow, a which point there will probably be logical ways to split the master repo without going all the way down to component granularity.
- Can't limit access to certain components for certain people.
- Can't git tag a specific component.  Since we use Maven versions for deployments (besides core), is this important?


Auditing git logs
-----------------
The git log command supports a <path> parameter.  This means that going into a component's directory and typing `git log .` will filter out any unwanted logs from other components (aka reproduce the current behavior for single-component-repos).