It would be nice to preserve the full history of the merged repos. You could either use git subtree for this or in the original repo move all files to the dir it would end up after the merge, commit and then merge from their repo into the main rust-analyzer repo. This second option was for example done when merging a big chunk of miri into rustc to be the new const-eval engine.

You've definitely thought about this, so can you articulate why you don't want to flatten everything into a single workspace? Your approach here somewhat seems to contradict your own article on managing large Rust workspaces.

The physical reason here is that crates in libs/* have a meaningful semver, while crates in crates/* don't. This kinds of reasons are a good motivation for adding some hierarchy. That's, eg, the reason behind the split of rust-lang/rust into /compiler and /library (incidentally, the remaining /src which contains just stuff is a good demonstarton why trees are hard).

So, we have independent versioning, and independent CI, and that's why we put them into /libs.

Makes sense, thanks for expanding on that.

If there won't be any path dependencies, you could even limit the new CI jobs to only run when those crates are changed by a PR (and conversely, have some of the current CI jobs only run when part of the big workspace is touched, though this might be harder).

Docs: https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths

We've moved the lsp-server into this repo, the other two I personally don't feel like we should move them in here (ungrammar maybe though I doubt that will really receive any more changes)