Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See

Jul 16, 2026

Upload by Eliana

Fork multiplicity inflates any repository-, author-, or popularity-based signal because many repositories share the same Git history. The work releases a curated deforking map for World of Code V2604 (p2PFull, cap250/cap500), collapsing raw repositories into canonical deforked projects using global shared-commit relations (51.79M groups) encoded by hub-node star structure and parallel Louvain clustering. Naive shared-history unions can overmerge mega-clusters; a capped residual is validated as genuine vendored history. Validation against GitHub ForkEvents yields 99.01% edge agreement and reveals cross-forge and detached-fork families platform graphs cannot represent.

LanguageEnglish

CategoryResearch & Report

FormatPDF

Pages9

Reading Time23 min

1 Introduction

2 Related Work

Deforking Map Contributions

Construction and Method

Deterministic Size Cap and Diagnostics

External Validation and Findings

Cross-Forge and Detached-Fork Analysis

Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See Audris Mockus University of Tennessee, Knoxville Knoxville, TN, USA [audris@utk.edu](audris@utk.edu) arXiv :2606 .29550v 3 [ cs . SE] 13 Jul 2026 Abstract Forks share git history, so a commit surfaces in many repositories and any spread-or popularity-based measure over raw repositories is inflated by orders of magnitude. We release a curated deforking map for the World of Code (WoC) version V2604: p2PFull, which collapses every raw repository 􀀿 into the deforked project 􀀥 to which it belongs, built from the global shared-commit relation (51 . 79M shared-commit groups) via a hub-node star encoding and parallel Louvain clustering, plus capped variants (cap250/cap500) that bound mega-cluster size. The naive shared-history union overmerges: the project graph welds unrelated software into giant clusters (largest uncapped cluster 443,010 repositories, bridged by shared-commit groups as large as 267,200), for the same structural reason author-identity graphs do. A cheap size cap removes the boilerplate-hub bridges; a structural-bridge diagnostic, the cut that dissolved the analogous author mega-cluster, run here but deliberately not applied, shows the post-cap residual is genuine vendored history, robust to the cut, so we leave it intact. We validate the map against GitHub’s declared fork graph reconstructed from GHArchive ForkEvents, finding 99. 01% edge agreement conditional on both repositories being in WoC. Disagreements fall into two classes: a completeness byproduct (edges GitHub asserts but WoC has not ingested) and the central contribution, WoC-only fork families that GitHub’s platform graph cannot represent, including 5. 53% multi-forge families and 1. 54% whose fork root is not on GitHub. We additionally release a refreshed fork-exclusion list (134 . 1M children, 3.4× the GHTorrent-era 39. 5M) and a detachedfork inventory (455,550 hard-detached edges; 240,441 genuine independent origins). All artifacts are a self-contained, independently hosted replication package keyed to the WoC V2604 collection. Keywords World of Code, deforking, fork detection, software provenance, mining software repositories, GHArchive, cross-forge 1 Introduction Mining software repositories at global scale must contend with forking: a single upstream history is copied into thousands of derived repositories, so a commit, a file, or an author appears to span far more “projects” than it truly does. Left uncorrected, every spread-, reach-, and popularity-based signal (author breadth, project size, dependency fan-out) is inflated by the fork multiplicity. Deforking, the recovery of the canonical project a repository belongs to, is therefore a prerequisite construction for any global-scale analysis, and it is exactly as error-prone as author-identity disambiguation: the obvious shared-history union over-merges catastrophically, and the fix requires the same precision discipline. This paper releases a deforking map for the World of Code (WoC) V2604 collection, extending the original shared-commit deforking approach [7] to the current collection, and documents both its construction and its external validation. Our contributions are the released artifacts and four findings about them, recorded as a living experiment log (Exps. D1–D5): • Themapandits capped variants (p2PFull, cap250/cap500): a repository→project provenance map over 51. 79M sharedcommit groups, mega-cluster controlled (Exp. D1) . • A structural diagnostic showing the post-cap residual is genuine shared (vendored) history rather than a clustering artifact, robust to the cut (Exp. D2), with its measured effect on the spread signal (Exp. D3) . • External validation against GitHub’s declared fork graph from GHArchive ForkEvents: 99. 01% edge agreement conditional on both endpoints in WoC, plus a completeness byproduct (Exp. D4) . • Cross-f

FAQs

Why does fork multiplicity distort global mining results?

Because many derived repositories share the same upstream Git history, commits, authors, and other signals appear to span far more “projects” than they truly do, inflating spread and popularity measures.

How does the deforking map assign raw repositories to canonical projects?

It collapses each raw repository into its deforked project using the global shared-commit relation, encoded via a hub-node star structure and clustered with parallel Louvain, with optional capped variants to control mega-cluster size.

How was the map validated against GitHub data?

The work reconstructs GitHub’s declared fork graph from GHArchive ForkEvents and compares edges, achieving 99.01% edge agreement when both endpoints are in the World of Code collection, with disagreement analyzed into completeness byproducts and WoC-only fork families.

Jul 16, 2026

Upload by Eliana