When would I choose meta in preference to repo a.k.a. git-repo ?

[k1eran]

When would I choose meta in preference to repo a.k.a. git-repo ?

Re. repo at https://gerrit.googlesource.com/git-repo/ it seems to do same job? What is core difference & when do you advice us to choose one over the other?

Furthermore the README says meta has

no strange side effects of git submodules or subtree

but what exactly are the these problems? Why is meta better than submodules?

I think this info would be helpful in the project README.

I am a total newbie with meta so apologies if my questions are too simple.

[patrickleet]

Hi, haven't seen git-repo until now. I also recently saw gico which is similar as well.

meta itself is inspired from earlier usage of a tool called gitslave which did a good job summarizing the problem with git submodules several years ago.

Gitslave creates a group of related repositories—a superproject repository and a number of slave repositories—all of which are concurrently developed on and on which all git operations should normally operate; so when you branch, each repository in the project is branched in turn. Similarly when you commit, push, pull, merge, tag, checkout, status, log, etc; each git command will run on the superproject and all slave repositories in turn. This sort of activity may be very familiar to CVS and (to a lesser extent) Subversion users. Gitslave's design is for simplicity for normal git operations.

git-submodules is the legacy solution for this sort of activity. submodules went a different way where you have a submodule at a semi-fixed commit. It is a little annoying to make changes to the submodule due to the requirement to check out onto the correct submodule branch, make the change, commit, and then go into the superproject and commit the commit (or at least record the new location of the submodule). It was originally designed for third party projects which you typically do not doing active development on (it works the other way with a little inconvenience). Most git commands performed on the superproject will not recurse down into the submodules. As suggested above, submodules give you a tight mapping between subproject commits and superproject commits (you always know which commit a subproject was in for any given superproject commit).

This mismatch of use cases vs git submodule was likely the inspiration for tools like gico and git-repo as well, but I can't speak for their authors.

meta expands on this idea by allowing users to create a .meta file that contains a JSON object that describes all of the repositories that make up the project and perform any command against all or a subset of those projects. It also is an extensible plugin based core, and thus can expand to more use cases than just git. For example, the meta-npm plugin provides lerna-like "npm linking" capabilities, and I used "meta project migrate" just this morning to split a monorepo up to the seven different sub-projects that made it up.

Thera are some usage scenarios here as well: https://github.com/mateodelnorte/meta#usage-scenarios

[mateodelnorte]

@k1eran last I looked at repo, it had a whooooole lot of convention that was tightly coupled to Android development. At the very least it would cause you to have to overlook a bunch of cruft you don't need in your solution. At the worst, it might not work. I didn't try hard enough to see if the second option was reality. If you want to invest time in it, I'd be happy to hear back about your experience.

The intention behind meta was to create the simplest tool possible, using first principles. How can I use the simple, basic concepts in git to extend git's functionality? That's meta.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[milahu]

my first impression: git submodules are not bad enough to justify adding a new tool

see also #311

[patrickleet]