Conversation

This Tweet is from a suspended account. Learn more

Replying to

and

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

Replying to

and

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.

platform_manifest/default.xml at 350828e2946fde6d1bbf15070fba79c49e2a6a1a · GrapheneOS/platform_m...

Repo manifest for the GrapheneOS mobile privacy and security hardening project. - platform_manifest/default.xml at 350828e2946fde6d1bbf15070fba79c49e2a6a1a · GrapheneOS/platform_manifest

2

1

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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.

1

Replying to

and

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

Replying to

and

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.

wahoo extended support release repositories · GrapheneOS/platform_manifest@1113efe

6:10 AM · Apr 3, 2021Twitter Web App