To sum up, it looks like this is a server that provides smaller views of a large monorepo. A simple case is checking out a subdirectory of the repo and just get

To sum up, it looks like this is a server that provides smaller views of a large monorepo. A simple case is checking out a subdirectory of the repo and just getting the files and history for that subdirectory. They also advocate using these views to do builds. That way, your build can't depend on any files that are outside its view. It's a kind of sandboxing for builds. [1] > In particular when using C family languages, hidden dependencies on header files are easy to miss. For this reason limiting the visibility of files to the compiler by sandboxing is pretty much a requirement for reproducible builds. > With Josh, each deliverable gets its own virtual git repository with dependencies declared in the workspace.josh file. This means answering the above question becomes as simple as comparing commit ids. Furthermore due to the tree filtering each build is guaranteed to be perfectly sandboxed and only sees those parts of the monorepo that have actually been mapped. > This also means the deliverables to be re-built can be determined without cloning any repos like typically necessary with normal build tools. Bazel users might find this familiar. It does a similar thing by running build tools in a temporary directory that contains symlinks to your actual source code. But it's not something you actually need if you're not using a monorepo, since your package manager won't pull in other packages that you don't depend on. [1] https://josh-project.github.io/josh/usecases.html https://josh-project.github.io/josh/usecases.html