Conversation

This Tweet is from a suspended account. Learn more

Replying to

and

I think subtrees make more sense for tightly bound components and repo is a nicer approach than submodules for other things. Submodules are bad enough that both AOSP and Chromium invented their own versions of it to work around how broken/weird/painful they are to deal with.

Replying to

and

Yeah, I won't ever use/introduce submodules into a project if I can avoid it. I'm 100% for subtrees. Mainly because today's software w/ things like leftpad/mimemagic causing pain.

Replying to

and

I don't mind repo because it's simply a text file describing repositories via branch, tag, revision, etc. and it's nice to deal with for overriding repositories and so on. It essentially works like submodules if you reference things via revision which you do for a release.

Replying to

and

repo? as in gerrit/git-repo? Yeah, I'm not really into adding yet another build tool into the mix these days. It's a good way to prevent cross platform compatibility.

Replying to

and

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.

Replying to

and

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.

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.

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.

github.com

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

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.

5:37 AM · Apr 3, 2021Twitter Web App

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.

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.

Show replies