[vlad_ivanov]

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

[dayjaby]

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.

I'm joining the waiting list to check for this :)

[givel]

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.