As someone who's never heard of a metarepo before, I'm still not sure exactly what it is or why I should use it after reading their landing page. I think a metarepo explainer video would helpful.
Vlad from metahead here. We answer this in the FAQ – metarepo is just a git repo that you can slice and dice any way you want while preserving history and having the ability to work on your part of the code. We went with "meta" because it's not exactly mono- or poly- – it's flexible enough so that you can make anything out of it. It also stores information about how your repos / projections relate – in that sense it's "meta" as well.
“Meta” would normally mean that a metarepo relates to a repo like a repo relates to a file. That would imply an orthogonal versioning axis, similar to a bitemporal database.
I find the term confusing here because that’s not really what it is (if my understanding is correct).
It does, in fact, relate to a repo like a repo relates to a file! Because every projection only contains related history and subtrees – much like if you were looking at a history of a file in a git repository
You can, if histories are related. They usually are - you add commits on top. Your history will be reverse-transformed in such a way so that its impact on the whole metarepo can be assessed. So if you modified a file in a library that ten other applications depend on, those applications would get this modification applied and would trigger a CI run to verify your change.
Where is your FAQ? I couldn't find it in the first few pages of your websites. No link in the footer either. The only button in your navbar is "about" which is not it.
The readme is understandable and the failure modes means it degrades to an ordinary git repo.
> This git command "clones" an external git repo into a subdirectory of your repo. Later on, upstream changes can be pulled in, and local changes can be pushed back. Simple.
One of the reasons to have a mono repo is to avoid the mirroring of PRs between repos. If you have 40+ repos and each time a package gets updated and you need to raise 39 PRs to bump the package. It's getting really old to do mirroring etc.
Not sure how this is an improvement over using a mono repo
One thing to note is that we don't bump package versions but rather "mirror" the source code, so in that sense it works like a monorepo. But you're right that PR mirroring doesn't work beyond a certain point, and we certainly intend to scale beyond that in future
> Maintaining an open-source library as part of your proprietary codebase? You can use metahead to publish and synchronise part of your code in its own public repo. Accept external contributions and check them against your internal usage of the library. You have the choice to make as much or as little as you want public, with file-granularity filters.
I've wished for this in multiple open-source oriented companies.
We will add a FAQ entry about scalar and we have one about submodules. But in short, here's why you might want to use this instead of the existing solutions:
* sub-repos -- projections as we call them -- are still a part of the one big history. But the history is filtered on your end and you only see relevant commits. You don't need to manually bump the version of projections
* you could also get "one big history" behaviour with a traditional monorepo, but with projections you get benefits like fine-grained ACL
Why invent a new word like "projection" though? Literally everyone would have understood "subrepo" just as fine.
How does your dependency management integrate into workflows? Last month I built a monorepo with all our repositories. For workflows it was essential that if a subrepo changed, not just this subrepo but also all its dependants get rebuilt.
Regarding the word "projection", the thing is that you sync in multiple "sub"-repositories to the metarepo, but you can then recombine them dynamically from this repository. It's a projection as in it's a view, a slice of the metarepo that takes selected bits and combines them into an ad-hoc repository.
The metarepo contains a description of the relationship between those components (who contains whom), such that when you push to one of the contained, depended-on repositories, all the views that include it and as such depend on it get rebuilt.
You've also posted some good unpredictable comments so I definitely don't want to ban you. Basically, any form of predictability is what we're trying to avoid here.