I wouldn't call it a build tool. It's a fairly straightforward script for managing a bunch of Git repositories.
It's comparable to making a top-level repository with everything else as submodules, but without the pain of submodules, and very unopinionated about how you use it.
Conversation
The manifest is in a repository by itself with nothing else. If you want, you can refer to everything via specific revisions. Generally, you refer to stuff via tags or even branches for development and for a build you generate a frozen revision manifest with repo manifest -r.
1
1
This Tweet is from a suspended account. Learn more
As an example, this is the latest stable release of AOSP:
android.googlesource.com/platform/manif
GrapheneOS has a fork of this where we reference our repositories via branch for development and external projects by revision.
For builds/releases, we use repo manifest -r to make a frozen one.
1
1
This is our development branch one:
github.com/GrapheneOS/pla
This is what repo manifest -r makes:
github.com/GrapheneOS/pla
So, generally, when you do a build that's used beyond local development, you make one of those to go with it.
It's not a pretty tool but it works well.
2
1
I'm very thankful that I primarily have to deal with repo and not submodules. I like that it's very flexible in how you use it. A developer can add a local manifest overriding / extending the main one. Can also tag metadata to allow for different kinds of partial checkouts, etc.
1
It knows how to upload a set of changes across multiple repositories to Gerrit properly, which is how it fits in with Gerrit. It understands the concept of a branch across multiple repositories, etc. That's why it has that review metadata for the AOSP remote and can for multiple.
1
1
In theory, you get something from Git understanding submodules, but in practice, I find that it's just a massive pain to deal with and I'd rather Git didn't have a clue what was going on, like repo.
Can use repo with entirely frozen revisions like submodules, just not mandatory.
2
1
It's a lot easier referencing things by tag. It's convenient referencing them by branch to grab the most up-to-date version. Just need to keep in mind when referencing things by dynamic heads like branches to use repo manifest -r to snapshot exactly what you cloned from it.
2
This Tweet is from a suspended account. Learn more
Yeah, that's the main usage of repo with AOSP. This is the master one:
android.googlesource.com/platform/manif
Their CI infrastructure will generate a frozen manifest (as a repo.prop) for each of the builds it does.
Revision set on a remote is a default, and there can be multiple remotes.
So, for example, if AOSP drops a repository (deletes it from manifest) but we still want it, we can add it back with the same remote, and set a specific tag/revision on that repository. Don't need to fork it unless we need to change it. It's extremely flexible overall.
1
By convention, repository with the manifests has a matching tag / branch for what it references. You can put anything in it though.
For example, github.com/GrapheneOS/pla is how we do our extended support branch for devices AOSP dropped, and that gets tagged frozen manifests too.