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.
Conversation
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.
2
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.
2
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.
2
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.
1
1
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.
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