Microsoft Office migration from Source Depot to Git

Original Article ↗ Hacker News Discussion ↗

Legacy Microsoft tooling and evolution

  • Commenters note Microsoft long relied on “ancient” internal tools yet still shipped huge products; several argue those tools were actually advanced for their time (e.g., early code coverage, powerful debuggers, sophisticated test farms).
  • Others emphasize Office predates Git by 15+ years, so it was natural for it to have grown up on custom systems.
  • Some say Microsoft often innovated but failed to capitalize (e.g., AJAX, NetDocs vs Office).

Source Depot / Perforce vs Git and monorepos

  • Source Depot is described as a Perforce fork, once highly advanced, especially for very large centralized monorepos like Windows and Office.
  • Key SD/Perforce feature praised: directory mapping / sparse client views, including remapping directories and sharing files across projects; some argue this would remove much monorepo tooling complexity if Git had it natively.
  • Others found directory mapping confusing in practice (fragile workspace mappings, outdated wikis) and preferred Git’s simpler, fixed layout and modern sparse-checkout/VFS features.

Sparse views, VFS, and filesystem tangents

  • Debate on whether Git’s limitations are really about Git or about underlying filesystems; some briefly suggest ZFS and snapshots, others counter that SD’s strengths were at the VCS layer, not FS.
  • Microsoft’s VFS for Git is highlighted as essential for scaling Office-sized repos; it brings Git closer to Perforce’s “only fetch what you touch” model.

Submodules and dependency management

  • Some propose Git submodules as the “answer” to cross-repo dependencies; multiple replies call submodules awful in practice and unrealistic because consumers rarely update them reliably.

Perforce, binaries, and game / asset-heavy workflows

  • Strong consensus that Perforce still dominates game dev and other asset-heavy domains: excellent with huge binary assets, locking for unmergeable files, easier purging of old revisions, and better support in tooling.
  • Several argue Git LFS remains slow, fragile, and disk-hungry at multi-hundred-GB or TB scales; Perforce is seen as “the only game in town” for those use cases despite being expensive and awkward.

Other Microsoft SCMs: VSS, TFS, SLM

  • Long subthread on Visual SourceSafe: widely remembered as unreliable, corruption-prone, and SMB-locking-based; often called “source destruction,” yet still considered better than no VCS at all.
  • TFS/TFVC is recalled as an improvement over VSS and decent for centralized workflows, but it never scaled to Windows/Office monorepo needs like SD did.
  • Older internal system SLM (“slime”) is mentioned as pre-SD, suffering from shared-filesystem scaling problems.

Forward/Reverse Integration (RI/FI) in SD

  • Explained as structured flows between long-lived branches and main: RI and FI describe direction of merges between product branches and trunk.
  • Some note even within Microsoft different groups used RI/FI terminology in opposite directions, underlining the complexity of branch hierarchies.

Communication and migration change management

  • The article’s description of over-communicating migration details (emails, Teams, docs, talks, office hours) resonates; multiple commenters contrast this with their own employers’ single-email, last-minute deletions.
  • Discussion of “communications fatigue”: high volume of irrelevant corporate mail leads many engineers to skim or ignore messages, making even critical notices easy to miss; others argue filtering and information management are core professional skills.

Git ubiquity, skills, and big-tech culture

  • Some are skeptical that many Office engineers had never used Git by the time of migration; others counter that many long-tenured Microsoft developers don’t code as a hobby, had contracts discouraging side projects, and lived entirely inside internal tooling.
  • Using Git is framed as valuable “transferable skill”; migration reportedly halved onboarding time and made Microsoft experience more industry-relevant.
  • There’s worry about big-tech “bubbles” where people spend decades without exposure to external ecosystems (Git, FOSS, non-Windows platforms).

Future of version control and alternatives

  • Several note Git’s dominance but argue it’s not “end of history”: Mercurial, Fossil, jj, Meta’s Sapling, Google’s Piper, and PlasticSCM are cited as active alternatives, especially for large monorepos or binary-heavy workflows.
  • Commenters stress DVCS isn’t always superior: centralized systems can reduce merge pain and better support strong coordination, especially when integrated deeply with build and filesystem tooling.
  • Others point out Git itself had to be heavily extended (partial clone, sparse checkout, commit-graph, packfile improvements) by large companies to handle “Office/Windows scale,” showing continuing room for innovation.