Comment by ramanujan | Hacker News Reader

Comment by ramanujan | Hacker News Reader

This looks like it could be of assistance:

http://source.android.com/source/version-control.html

  Repo is a repository management tool that we built on top 
  of Git. Repo unifies the many Git repositories when 
  necessary, does the uploads to our revision control 
  system, and automates parts of the Android development 
  workflow. Repo is not meant to replace Git, only to make 
  it easier to work with Git in the context of Android. The 
  repo command is an executable Python script that you can 
  put anywhere in your path. In working with the Android 
  source files, you will use Repo for across-network 
  operations. For example, with a single Repo command you 
  can download files from multiple repositories into your 
  local working directory.

http://google-opensource.blogspot.com/2008/11/gerrit-and-rep...

  With approximately 8.5 million lines of code (not 
  including things like the Linux Kernel!), keeping this all 
  in one git tree would've been problematic for a few reasons:

  * We want to delineate access control based on location in the tree.
  * We want to be able to make some components replaceable at a later date.
  * We needed trivial overlays for OEMs and other projects who either aren't ready or aren't able to embrace open source.
  * We don't want our most technical people to spend their time as patch monkeys.

  The repo tool uses an XML-based manifest file describing 
  where the upstream repositories are, and how to merge them 
  into a single working checkout. repo will recurse across 
  all the git subtrees and handle uploads, pulls, and other 
  needed items. repo has built-in knowledge of topic 
  branches and makes working with them an essential part of 
  the workflow.

Looks like it's worth taking a serious look at this repo script, as it's been used in production for Android. Might allow splitting into multiple git repositories for performance while still retaining some of the benefits of a single repository.

> Looks like it's worth taking a serious look at this repo script, as it's been used in production for Android. Might allow splitting into multiple git repositories for performance while still retaining some of the benefits of a single repository.

Stay away from Repo and Gerrit. I use them at work, and they make my life miserable.

Repo was written years ago when Git did not have submodules, a feature where you can put repositories inside repositories. Git submodules is far superior to Repo, and allows you to e.g. bisect the history of many repositories.

I'm hoping that Google comes to it's senses and starts phasing out Repo in favor of Git submodules in Android development.

What about gerrit?

Compared to the code review facilities in GitHub, Gerrit is pretty crappy. Gets the job done, but the UI and the work flow it forces is a bit annoying.

The worst part in repo + gerrit is that their default work flow is based on cherry-picking and they introduce a new concept called Change-Id. The Change-Id basically yet another unique identifier for changes that is stored in the commit message. The intent is that you make a change (a single commit patch), a post-commit hook adds the Change-Id to the commit message and then you upload it for review. When you make additions to your change, the previous change gets overwritten. Gerrit tries to maintain some kind of branching (called dependencies), but they mess things up when there's more than one person working on a few changes at the same time.

In comparison with GitHub-style work flow where you make a branch with multiple commits, submit a pull request, get review, add commits, squash and merge, the repo + gerrit model is awfully constraining.

We might be using an old version of repo and/or gerrit and some of the issues I've encountered may be improved. However, I think that repo+gerrit is a mess beyond repair and trying to "fix" it only makes things worse.

Unless you work on Android and are forced to use repo+gerrit because Google does so, stay out of it.

I'm using it, the workflow isn't so bad. In fact it is similar to the way kernel patches are iterated and reviewed, except centralised instead of e-mail based.

Basically, if you want to manage a large collection of git source repositories, you'll probably end up using Repo and Gerrit and piggybacking on the work of the android ecosystem (and beyond, gerrit is used all over the place now)

There really isn't another solution out there right now (at least not anything open source) for very large single repositories.

> There really isn't another solution out there right now

What about Git submodules? They do fundamentally the same thing as Repo, but it's a built-in Git feature and not a bunch of scripts.

Repo can make your life very hard and you have to be a black belt Git ninja to understand what's going on when things don't go as you intended. Git submodules don't depend on having arbitrary GUID strings in your commit messages either (like Repo's Change-Id).

GitHub's reviews can handle Git submodules (but it's not free or open source). If someone knows any open source code review tools that can handle, please tell us.

Sorry for beating a dead horse, but I really want to save someone from fucking up (or at least re-centralizing) their workflow with repo scripts, when native git is better.

Having worked with repo professionally, I'm not a fan. You lose simple ability to track dependencies across repositories or even revert to a previous consistent point in time without diligent tagging. Even with good tags, restructuring your project setup and changing your repo manifest can still break your ability to go back in time.

Reply on news.ycombinator.com