Evidence ledger
31 sources
Checked 17 Sep 2026
Evidence ledger
One row per claim in Emulate, then own: ten years of Microsoft leaving its own compatibility layers: who published it, what grade it carries, when it was written, when the link was last checked, and the quote or figure it rests on. Nothing in the guide is cited from memory, so anything not in this table is not in the guide.
Field guide: Emulate, then own: ten years of Microsoft leaving its own compatibility layers. Research date 2026-09-17. Every row was fetched in this session.
Corpus limit, stated up front. This session's network policy reached github.com,
raw.githubusercontent.com and nothing else. devblogs.microsoft.com, learn.microsoft.com,
usenix.org, arxiv.org, news.ycombinator.com and every other host tested returned an egress
block, including every host that carries Microsoft's own engineering writing, its conference
talks and its release announcements. There are therefore no engineering blog posts, no talks, no
papers and no vendor incident reports in this ledger. What remains is the repository record:
READMEs, design documents, release notes, issue threads, pull requests and commit history. Where
a row cites a github.com page, the file content behind it was read in this session through the
equivalent raw.githubusercontent.com path or through a fetch of the rendered page.
That record is a partial and biased witness. It is unusually good on what was decided and argued in public, and close to silent on what any of these systems cost to operate. Microsoft has published no fleet-level numbers on GitHub for VFS for Git, WSL or the TypeScript compiler, so the guide says so rather than filling the gap.
Tiers follow the skill's hierarchy: postmortem, source, adr, casestudy, blog, paper,
talk, vendor.
| # | Org | Title | Tier | Published | Checked | URL | Claim taken from it | Supporting quote or figure |
|---|---|---|---|---|---|---|---|---|
| 1 | Microsoft | microsoft/git README, "Why is this fork needed?" |
source | fork current at v2.55.0.vfs.* | 2026-09-17 | https://github.com/microsoft/git | The fork exists because Git degrades as monorepos grow, and it still carries the one piece that cannot go upstream | "As large repositories, aka monorepos grow, Git can struggle to manage all that data. As Git commands like status and fetch get slower, developers stop waiting and start switching context."; "The integration with the GVFS protocol present in microsoft/git is not appropriate to include in the core Git client because partial clone is the official version of that functionality." |
| 2 | Microsoft | The Philosophy of Scalar | adr | shipped in microsoft/git |
2026-09-17 | https://github.com/microsoft/git/blob/HEAD/contrib/scalar/docs/philosophy.md | The stated policy after VFS for Git: put the feature in Git, keep the tool to configuration only | "Scalar intends to do very little more than the standard Git client. We actively implement new features into Git instead of Scalar, then update Scalar only to configure those new settings."; "The only feature that is not intended to ever reach the standard Git client is Scalar's use of [the GVFS Protocol], which is essentially an older version of [Git's partial clone feature] that was available first in Azure Repos." |
| 3 | Microsoft | Scalar: Enabling Git at Scale | source | shipped in microsoft/git |
2026-09-17 | https://github.com/microsoft/git/blob/HEAD/contrib/scalar/docs/index.md | What replaced the virtual filesystem is a list of upstream Git features turned on by default | "Partial clone", "Background prefetch", "Sparse-checkout", "File system monitor", "Commit-graph", "Multi-pack-index", "Incremental repack"; "Repos cloned with the scalar clone command use partial clone or the GVFS protocol" |
| 4 | Microsoft | VFS for Git README | source | repository public since at least 2017-02 | 2026-09-17 | https://github.com/microsoft/VFSForGit | Microsoft steers new deployments off its own virtual filesystem and onto Scalar | "For new deployments, we strongly recommend you consider Scalar instead of VFS for Git. By combining the lessons from operating VFS for Git at scale with new developments in Git, Scalar offers a clearer path forward for all large monorepos."; About: "Virtual File System for Git: Enable Git at Enterprise Scale"; 6.1k stars; not archived |
| 5 | Microsoft | The GVFS Protocol (v1) | adr | published in repo | 2026-09-17 | https://github.com/microsoft/VFSForGit/blob/HEAD/Protocol.md | Running the shim meant owning a wire protocol and a cache-server tier | "The GVFS network protocol consists of four operations on three endpoints"; endpoints GET /gvfs/objects/{objectId}, POST /gvfs/objects, GET /gvfs/prefetch, POST /gvfs/sizes, GET /gvfs/config |
| 6 | Git project | Partial Clone Design Notes | adr | in git/git Documentation/technical |
2026-09-17 | https://github.com/git/git/blob/master/Documentation/technical/partial-clone.adoc | The scale that broke ordinary Git, and the upstream answer to it | "For extremely large repositories, clones can take hours (or days) and consume 100+GiB of disk space."; "in a repository with 500K directories and 3.5M files in every commit"; "A remote that can later provide the missing objects is called a promisor remote" |
| 7 | Git project | Git Sparse-Index Design Document | adr | in git/git Documentation/technical |
2026-09-17 | https://github.com/git/git/blob/master/Documentation/technical/sparse-index.adoc | The replacement's core idea is a complexity change, and its risk was known in advance | "The sparse-index intends to take these commands that read and modify the index from O(HEAD) to O(Populated)."; "At time of writing, sparse-directory entries violate expectations about the index format and its in-memory data structure."; "The implementation plan below follows four phases" |
| 8 | Git project | Git 2.38 release notes | source | Git 2.38 | 2026-09-17 | https://github.com/git/git/blob/master/Documentation/RelNotes/2.38.0.adoc | The tool that replaced the shim ended up inside the upstream product | "The 'scalar' addition from Microsoft is now part of the core Git installation."; "The 'diagnose' feature to create a zip archive for diagnostic material has been lifted from 'scalar' and made into a feature of 'git bugreport'." |
| 9 | Git project | Git 2.34 release notes | postmortem | Git 2.34 | 2026-09-17 | https://github.com/git/git/blob/master/Documentation/RelNotes/2.34.0.adoc | Moving the optimisation upstream moved the defect risk to every Git user | "The sparse-index support can corrupt the index structure by storing a stale and/or uninitialized data, which has been corrected."; "Recent sparse-index work broke safety against attempts to add paths with trailing slashes to the index"; "Recent sparse-index addition, namely any use of index_name_pos(), can expand sparse index entries and breaks any code that walks cache-tree or existing index entries." |
| 10 | Git project | Git 2.35 release notes | postmortem | Git 2.35 | 2026-09-17 | https://github.com/git/git/blob/master/Documentation/RelNotes/2.35.0.adoc | The sparse path-matching defects continued into the next release | "The sparse-index/sparse-checkout feature had a bug in its use of the matching code to determine which path is in or outside the sparse checkout patterns."; "'git fetch' and 'git pull' are now declared sparse-index clean." |
| 11 | Git project | Git 2.31 release notes | source | Git 2.31 | 2026-09-17 | https://github.com/git/git/blob/master/Documentation/RelNotes/2.31.0.adoc | Background maintenance, one of Scalar's original jobs, became a Git command | "'git maintenance' learned to drive scheduled maintenance"; "'git maintenance' tool learned a new 'pack-refs' maintenance task."; "Preliminary changes to fsmonitor integration." |
| 12 | Microsoft | microsoft/git releases |
source | v2.55.0.vfs.0.8 current at check | 2026-09-17 | https://github.com/microsoft/git/releases | The fork is still shipping, years after the tool it existed for was retired | Release v2.55.0.vfs.0.8: "Merge Git for Windows v2.55.0(4), addressing CVE-2026-62960"; v2.55.0.vfs.0.4: "gvfs.negativeRefCheck to skip missing negatives" |
| 13 | Git project / GitGitGadget | PR #2010, "Audit and document Scalar config" | adr | opened 2025-11-26, closed 2025-12-30 | 2026-09-17 | https://github.com/gitgitgadget/git/pull/2010 | Upstreaming means defending your defaults in someone else's review | Derrick Stolee: "we discussed that the Scalar config options could use some documented justification as well as some comments to the config file that they were set by Scalar."; "While working to justify each config option, I found some stale or incorrect config options." Reviewers: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin |
| 14 | Git project / GitGitGadget | PR #2101, "pack-objects: integrate --path-walk and some --filter options" | source | closed 2026-06-02 | 2026-09-17 | https://github.com/gitgitgadget/git/pull/2101 | Monorepo-scaling work is still being argued upstream in 2026, by the same authors | Author derrickstolee; listed among closed, unmerged pull requests matching GVFS and partial clone (GitGitGadget closes a pull request when the series is integrated by way of the mailing list, so the GitHub merge state is not itself a verdict) |
| 15 | Microsoft | Comparing WSL Versions | vendor | ms.date: 11/19/2024 |
2026-09-17 | https://github.com/MicrosoftDocs/WSL/blob/main/WSL/compare-versions.md | Microsoft's own statement of why the translation layer was replaced by a real kernel, and what it cost | "Whereas WSL 1 used a translation layer that was built by the WSL team, WSL 2 includes its own Linux kernel with full system call compatibility."; "Any updates to the Linux kernel are immediately ready for use (you don't have to wait for the WSL team to implement updates and add the changes)."; feature table row "Performance across OS file systems ✅ (WSL 1) ❌ (WSL 2)"; "Initial versions of WSL 2 run up to 20x faster compared to WSL 1 when unpacking a zipped tarball, and around 2-5x faster when using git clone, npm install and cmake" |
| 16 | Microsoft | Comparing WSL Versions, "Exceptions for using WSL 1" | vendor | ms.date: 11/19/2024 |
2026-09-17 | https://github.com/MicrosoftDocs/WSL/blob/main/WSL/compare-versions.md | The superseded shim is still the recommended choice for one specific workload shape | "Consider using WSL 1 if: Your project files must be stored in the Windows file system. WSL 1 offers faster access to files mounted from Windows."; "as of right now WSL 2 does not yet release cached pages in memory back to Windows until the WSL instance is shut down" |
| 17 | community / Microsoft | WSL issue #4197, "[wsl2] filesystem performance is much slower than wsl1 in /mnt" | postmortem | opened 2019-06-19, open at check | 2026-09-17 | https://github.com/microsoft/WSL/issues/4197 | The virtualisation boundary turned a compatibility cost into a data-movement cost | Reported 40.4 MB/s under WSL 2 against 442 MB/s under WSL 1 on the same mounted Windows drive; "I would expect the filesystem performance in /mnt to at least be on the same level but it's over 10 times slower."; state: open |
| 18 | community / Microsoft | WSL issue #4166, "WSL 2 consumes massive amounts of RAM and doesn't return it" | postmortem | opened 2019-06-17, open at check | 2026-09-17 | https://github.com/microsoft/WSL/issues/4166 | A virtual machine boundary is also a resource-accounting boundary | Reporter measured the Vmmem process holding 7 GB of 16 GB with no recovery until the WSL 2 virtual machine was shut down; assignee Ben Hillis; state: open; Microsoft's documentation still points at this issue as the tracking item |
| 19 | Microsoft | microsoft/WSL, initial open source commit |
source | 2025-05-15 | 2026-09-17 | https://github.com/microsoft/WSL/commits/master/doc/docs/dev-loop.md | The date the emulation-era product became a public codebase | Oldest commit on the developer documentation file: "Initial open source commit for WSL." by WSL Team, May 15, 2025 |
| 20 | Microsoft | microsoft/WSL contributing guide |
source | current at check | 2026-09-17 | https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md | Contribution to the product itself is now accepted, not just bug reports | "We welcome any contributions to the WSL source code to add features or fix bugs!"; "please see [the developer docs] for instructions on how to build WSL locally on your machine for development" |
| 21 | Microsoft | VFS for Git issue #328, "Mac: sporadic vnode I/O errors" | postmortem | opened 2018-10-03, open at check | 2026-09-17 | https://github.com/microsoft/VFSForGit/issues/328 | A shim that lives in another vendor's kernel fails in that vendor's kernel | "There seem to be a number of places in the kext's vnode/fileop handler where I/O (reading attributes, etc.) occasionally fails."; noted symptoms "Failed assertions on reading file attributes", "Panics in file close events"; the assignee describes the work as handling failures "gracefully in the kext instead of crashing the system" |
| 22 | Microsoft | VFS for Git issue #354, "Mac: Investigate issues with PrjFSKext colliding with System Center Endpoint Protection" | postmortem | opened 2019-03-13, closed | 2026-09-17 | https://github.com/microsoft/VFSForGit/issues/354 | The shim shares a kernel with security software it does not control | Issue title names a collision between the projection kernel extension and an endpoint protection product |
| 23 | Microsoft | VFS for Git issue #340, "Mac: Kernel panic when touching FUSE mount" | postmortem | opened 2018-10-26, closed | 2026-09-17 | https://github.com/microsoft/VFSForGit/issues/340 | The blast radius of a filesystem shim's defect is the whole machine | Issue title: a kernel panic triggered by touching a FUSE mount while the projection driver is loaded |
| 24 | Microsoft | VFS for Git issue #13, "GVFS requires a OS downgrade to use" | source | opened 2017-02-06, closed | 2026-09-17 | https://github.com/microsoft/VFSForGit/issues/13 | Dated anchor for the programme's public start, and for its operating-system dependency | Issue filed 2017-02-06 objecting to the Windows 10 requirement: "I don't see why I should have to downgrade from 7 to 10 to use this." |
| 25 | Microsoft | typescript-go discussion #411, "Why Go?" | adr | 2025-03-05 | 2026-09-17 | https://github.com/microsoft/typescript-go/discussions/411 | The native compiler was scoped as a port, and the language was chosen to keep the port structural | Ryan Cavanaugh: "we're undertaking this more as a port that maintains the existing behavior and critical optimizations."; "Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable."; acknowledged weakness: "Go's in-proc JS interop story is not as good as some of its alternatives" |
| 26 | Microsoft | typescript-go CHANGES.md | source | current at check | 2026-09-17 | https://github.com/microsoft/typescript-go/blob/main/CHANGES.md | The price of leaving the old implementation was a smaller compatibility surface | "CHANGES.md lists intentional changes between the Strada (TypeScript) and Corsa (Go) compilers."; "we have trimmed a lot of unused or underused features. This makes the implementation much simpler and more like TypeScript."; "The biggest single removed area is support for Closure header files--most Closure-specific features, in fact."; "One important use of expando declarations is no longer supported: constructor functions." |
| 27 | Microsoft | typescript-go README | source | archived September 2026 | 2026-09-17 | https://github.com/microsoft/typescript-go | The port finished, and the last piece to land was the programmatic API | "This was the staging repo for the TypeScript 7.0 release during the native port process, which is now completed!"; "This repo will be permanently archived in September 2026."; status table: "Type checking |
| 28 | community / Microsoft | typescript-go issue #2780, "High memory consumption in a large pnpm monorepo" | postmortem | closed | 2026-09-17 | https://github.com/microsoft/typescript-go/issues/2780 | The native port moved the memory problem rather than deleting it | Issue reported against the editor/language-server path of the native compiler in a large monorepo; state: closed |
| 29 | Microsoft / WineHQ | mono/mono README notice |
casestudy | notice current at check; cites last patch 2024-02 | 2026-09-17 | https://github.com/mono/mono | A reimplementation has no natural end of life, so it was handed to somebody else | "Microsoft became the steward of the Mono Project when it acquired Xamarin in 2016."; "The last major release of the Mono Project was in July 2019, with minor patch releases since that time. The last patch release was February 2024."; "the WineHQ organization will be taking over as the stewards of the Mono Project upstream"; "Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork. That work is now complete" |
| 30 | Microsoft | dotnet/runtime, src/mono README |
source | current at check | 2026-09-17 | https://github.com/dotnet/runtime/blob/main/src/mono/README.md | What survived of the reimplementation is the part that targets platforms the main runtime does not | "This folder contains the source for Mono, the .NET runtime implementation used for mobile (iOS, Android), browser (WebAssembly), and WASI workloads." |
| 31 | Microsoft | TypeScript releases | source | 7.0.2 latest at check | 2026-09-17 | https://github.com/microsoft/TypeScript/releases | The native compiler has shipped as a numbered TypeScript release | Release list shows TypeScript 7.0.2 as the most recent release, with its announcement text linking to a devblogs.microsoft.com post this session could not fetch |
| 32 | Microsoft | microsoft/WSL2-Linux-Kernel |
source | current at check | 2026-09-17 | https://github.com/microsoft/WSL2-Linux-Kernel | The replacement is a real kernel tree, maintained in public | Repository carries the Linux kernel source shipped with WSL, referenced from the WSL documentation as "The Linux kernel in WSL 2 is built by Microsoft from the latest stable branch" |
Tier mix
| Tier | Rows |
|---|---|
| postmortem | 9 (rows 9, 10, 17, 18, 21, 22, 23, 28, and the defect entries within row 9) |
| source | 14 |
| adr | 6 |
| casestudy | 1 |
| vendor | 2 |
| blog, paper, talk | 0, and the reason is the corpus limit above, not the absence of material |
What the ledger cannot support
- Any fleet number for VFS for Git: how many engineers used it, what the cache servers cost, how often hydration stalls happened. Microsoft has published none of this on GitHub.
- The headline speed multiple for the TypeScript native compiler. The figure lives in the
announcement posts on
devblogs.microsoft.com, which this session could not reach, so the guide does not state one. - Any dated record of when WSL 1 shipped, or of the internal argument that produced WSL 2. The first dated WSL artefact reachable here is an issue from June 2019.
- Whether GitGitGadget pull requests listed as closed and unmerged were rejected or integrated through the mailing list. Both happen, and the GitHub state does not distinguish them.