Microsoft Scalar: the monorepo tooling that moved into Git itself

The feature list is a list of Git features, not of inventions

Scalar is a tool that helps Git scale to some of the largest Git repositories, and the way it achieves that is the interesting part. It does it by enabling some advanced Git features, and the project summary enumerates them.

Partial clone reduces the time to get a working repository by not downloading all Git objects right away. Background prefetch downloads Git object data from all remotes every hour, reducing the amount of time for foreground `git fetch` calls. Sparse-checkout limits the size of your working directory. The file system monitor tracks the recently modified files and eliminates the need for Git to scan the entire worktree. The commit-graph accelerates commit walks and reachability calculations, speeding up commands like `git log`. The multi-pack-index enables fast object lookups across many pack-files. Incremental repack repacks the packed Git data into fewer pack-files without disrupting concurrent commands by using the multi-pack-index.

Every one of those is a Git feature. None of them is a Scalar feature. Scalar's job was to turn them on, in the right combination, for a repository.

That last point explains the feature list. The project also says that as new versions of Git are released, Scalar updates the list of features it automatically configures, and that this reduces your effort to keep your repositories as efficient as possible. So the value of the tool was never a proprietary implementation, it was the configuration, the defaults, and the knowledge of which combination works.

The description in the repository is precise about the goal, a set of tools and extensions for Git to allow very large monorepos to run on Git without a virtualization layer. Avoiding a virtualization layer is the whole point. The predecessor was a virtualization layer, and a virtualization layer means a background process, a virtual file system, and a mount, all of which are things that can go wrong and that you have to install and maintain on every machine.

The project moved, and the repository is now a pointer

The project summary has a section titled Scalar has moved, and it is the most important thing to read before anything else.

Through significant effort from the team, Scalar has been transitioned from a modified version of VFS for Git into a thin shell around core Git features. The Scalar executable has now been ported to be included in the `microsoft/git` fork, and the project says to visit that fork for all of your Scalar needs: download the latest `microsoft/git` release, read the Scalar documentation there, and contribute changes to the `scalar` CLI.

The `scalar` CLI now lives in a C file, at `contrib/scalar/scalar.c` in the fork, and the documentation is at `contrib/scalar/docs/index.md`. So the executable that used to be a.NET application is now a small command line program inside a Git distribution.

The reason for the move is explained in a section titled why did Scalar move. Scalar started as a modification of VFS for Git to create a working solution with a test suite in a short amount of time, and the goal was to depend more on features that exist within Git itself instead of creating new functionality within this project.

Then the work happened inside Git rather than inside Scalar. The project lists three efforts: improving sparse-checkout performance in Git, implementing background maintenance in Git, and integrating the GVFS protocol into `microsoft/git`, which allowed them to drop the `Scalar.Mount` process. All of these changes reduced the size of the code in Scalar itself until it could be replaced with a small command line interface.

That is a notable arc. A monorepo tool that started as a modified Git with a background daemon ended up as upstream Git features plus a small command line interface, and the daemon is gone. The stated additional benefit is that the release and installation mechanism became much simpler, since users now only need to install one tool rather than multiple.

What is left here is the test suite, and it still gates changes

The question of what remains in the repository is answered directly, and the answer is more interesting than a simple deprecation notice.

The repository is being kept available since the project has linked to it and wants to make sure those links continue to work, and pointers have been added in several places to navigate readers to the `microsoft/git` repository for the latest versions. So the repository is a signpost as much as an archive.

But the second paragraph is the substantive one. The project also has a large set of functional tests that verify that Scalar enlistments continue to work in a variety of advanced Git scenarios. These tests are described as incredibly helpful as the features advance in `microsoft/git`, so those tests remain in this repository. They are run as part of pull request validation in `microsoft/git`, so no changes are made there without passing this suite of tests.

That is a genuine architectural decision and an unusual one. The tests for a feature that now lives in another repository stayed behind in the old repository, and they are the gate for the new code. It means the .NET implementation is not dead weight in the tree, it is the reference behaviour that the C implementation in the fork must match.

The repository layout backs this up. There is a `Scalar.FunctionalTests/` directory, a `Scalar.TestInfrastructure/` directory, and a `Scalar.MSBuild/` directory, along with `Scalar.Signing/` and `Scripts/`. There is an `AuthoringTests.md` document and a `Protocol.md`, which describes the protocol the tool speaks. The build is a .NET solution, `Scalar.sln`, with `Directory.Build.props` and `Directory.Build.targets` for shared settings and `Dependencies.props` for versions, plus `nuget.config` and `global.json` for the toolchain. The CI configuration is in `.azure-pipelines/`, and there is a `Scalar.ruleset` for the static analysis rules, which is the Visual Studio code analysis rule set.

The primary language is C#, the licence is MIT with the terms in `License.md`, and the last push to the repository was on 2026-08-28.

The upgrade path differs on every platform

If you already installed Scalar and want the new version, the project describes a per-platform path, and the differences are not cosmetic.

On Windows, users can install `microsoft/git` and the installer will remove the .NET version of Scalar and update any registered enlistments to work with the new version. The installer does the cleanup and the migration.

On macOS, the instruction is to run `brew uninstall --cask scalar` or `brew uninstall --cask scalar-azrepos` depending on your version, and then run `brew install --cask microsoft-git` to get the new version. The caveat is that macOS users will need to re-run `scalar register` on their enlistments to ensure they are registered for future upgrades.

On Linux, there is no established uninstall mechanism, so the .NET version is removed by hand with `sudo rm -rf /usr/local/lib/scalar/`, and installing the new version overwrites the `scalar` binary in `/usr/local/bin`. Linux users also need to re-run `scalar register` on their enlistments.

The two facts worth noting are that macOS and Linux both require a manual re-registration step, and that Linux has no uninstall mechanism at all, so the removal is a recursive delete of a directory the user has to know the name of.

The way to check that the new version is installed correctly is to run `scalar version`, which should have the same output as `git version`. That check is the clearest signal of the architectural change: the new Scalar is a wrapper around Git, so its version is Git's version.

The two casks on macOS, `scalar` and `scalar-azrepos`, reflect that Scalar had more than one distribution on that platform, which is exactly the kind of complexity the move was meant to remove.

The version history explains why the repository looks frozen

The release tags tell you something the README does not, and it is worth reading them before concluding anything about the state of the project.

The three most recent releases are v21.03.185.1 from 2021-03-24, described as the March 2021 release, v21.02.999.2 from 2021-02-09, described as an Experimental Release, and v21.01.182.4 from 2021-01-14, described as the January 2021 release.

So the last release of the .NET Scalar was in March 2021, and the version numbers follow a date-based scheme with a build number, which is how Microsoft versions internally built tools. The February release is labelled experimental, which is a detail that tells you the release process for this tool was not fully settled.

That gap between the last release and the current date is the direct consequence of the move. The tool stopped being released from this repository when it moved into the `microsoft/git` fork, and the fork has its own release cadence, visible on the releases page rather than here.

So this repository's release history is not evidence that the project was abandoned in 2021. It is evidence that the project changed shape, and the release process followed the code. The work continued, in Git itself, and this repository kept the parts that had to stay behind: the test suite and the historical implementation.

The `SECURITY.md` file and the `CODE_OF_CONDUCT` reference are also present, the code of conduct being the Microsoft Open Source Code of Conduct, with a contact address for questions. The `docs/` directory holds the documentation that was written for this version, and `Images/` holds the card image used at the top of the project summary.

Where this repository is the wrong place to look

The practical advice is short, and the reason for it is the project's own history.

If you want the tool, this is the wrong repository. The Scalar executable is in the `microsoft/git` fork now, as a C command line interface, and the releases, the documentation, and the source for the CLI all live there. Installing a 2021 .NET release because you found this repository is a mistake, whatever the version tag suggests.

If you are evaluating whether Scalar is the right approach at all, the more useful question is which of the listed features you actually need, because each of them is available independently in modern Git and in the microsoft/git fork. Partial clone is a Git feature, sparse-checkout is a Git feature, the commit-graph and the multi-pack-index are Git features, and background maintenance was implemented in Git. Scalar's value was configuring them together and getting the enlistment registration right, and that is what the thin command line interface now does.

If you are on macOS or Linux, the migration has friction that Windows does not. Re-running `scalar register` on every enlistment is a manual step, and on Linux you also have to remove the old installation by deleting a directory yourself, because there is no uninstall mechanism. A team with many enlistments across many machines should plan for that rather than discover it.

If you are looking for the history of how Microsoft solved the monorepo problem, this repository is genuinely valuable. The list of efforts, the sparse-checkout performance work, the background maintenance implementation, the GVFS protocol integration that removed the mount process, and the functional test suite are all here, and they are a record of a large engineering programme that ended by being folded into the tool it was extending.

The final caution is about the test suite's role. Because the functional tests in this repository are the gate for pull requests in `microsoft/git`, a change to the fork can break behaviour that is only asserted here. If you are working on the fork, running this suite is not optional, which is the one place where this repository is still load-bearing rather than historical.

Editorial conclusion

This repository fits an engineer who is migrating from the .NET build of Scalar to the version in microsoft/git, because it is where the upgrade instructions and the functional test suite live, and it fits anyone who wants to understand how Microsoft's monorepo approach turned into upstream Git features. It is the wrong place to get Scalar itself, since the executable now ships in the microsoft/git fork. Check three things before you rely on anything here: that you are using the microsoft/git fork rather than this repository for the tool itself, that you read the Scalar documentation in the fork, and that you know this repository's code is the older .NET implementation, since the executable was ported to C.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/scalar on GitHub
4. README
5. Releases