# Missing Git Features for Modern Multi-Repository, Dependency-Driven Development 3 messages from 2026-06-01 to 2026-06-01. Participants: Skybuck Flying. Thread: https://gitlist.dev/t/65727 ## Skybuck Flying, 2026-06-01 20:57 Subject: Missing Git Features for Modern Multi-Repository, Dependency-Driven Development Message-ID: ``` Modern software projects increasingly rely on large dependency graphs, multi-repository structures, reproducible builds, and long-term provenance. Git provides excellent version control but lacks native mechanisms for these workflows. This RFC outlines optional, backward-compatible metadata extensions that would allow Git to better support modern development practices. This document contains three sections: 111. WHAT GIT SHOULD HAVE BEEN 222. RFC/PROPOSAL SECTION 333. EXAMPLE SECTION (Examples of why it would be usefull) *** 111. WHAT GIT SHOULD HAVE BEEN *** --- # ⭐ **REPORT: Missing Git Features Required for a Complete Modern System** Git is brilliant at what it *was designed for*: - content-addressable storage - distributed history - immutable snapshots But Git is **NOT** a complete software-engineering system. Below is the list of features Git *should* have had to avoid the chaos of: - meaningless import paths - dependency hell - submodule drift - missing provenance - missing security metadata - missing version semantics - missing reproducibility - missing dependency manifests These are the features Git is missing. --- # ⭐ 1. **A Built-In Dependency Manifest System** Git should have had: ### ✔ A first-class manifest file Something like: ˋˋˋ .gitdeps ˋˋˋ Containing: - dependency name - dependency URL - dependency version - dependency commit - dependency purpose - dependency license - dependency security metadata ### ✔ A built-in lockfile Something like: ˋˋˋ .gitdeps.lock ˋˋˋ Freezing: - exact commit hashes - exact versions - exact URLs ### ✔ Automatic dependency resolution Like Cargo, Go, npm, Maven, Gradle. ### ✔ Automatic dependency graph visualization Not “git submodule status”. ### ✔ Automatic reproducible builds Not “hope the submodules are correct”. --- # ⭐ 2. **Semantic Versioning Support** Git should have supported: ### ✔ Version numbers Not just tags. ### ✔ Version ranges Not just commit hashes. ### ✔ Version constraints Not just “latest tag”. ### ✔ Version compatibility rules Not just “merge and pray”. ### ✔ Version negotiation Not just “clone and hope”. --- # ⭐ 3. **Built-In Provenance Tracking** Git should have stored: ### ✔ Original upstream URL ### ✔ Fork lineage ### ✔ Migration history ### ✔ Renames ### ✔ Moves ### ✔ Repository identity This should have been **inside the repo metadata**, not: - lost - local only - dependent on remotes - dependent on GitHub - dependent on user discipline You should NEVER lose: - where a repo came from - who forked it - why it exists - what it was based on Git does not store this. It should. --- # ⭐ 4. **Built-In Security Metadata** Git should have had: ### ✔ CVE metadata per commit ### ✔ Security advisories per tag ### ✔ Vulnerability scanning ### ✔ Security provenance ### ✔ Signed dependency manifests ### ✔ Automatic alerts when upstream is compromised Instead, we have: - nothing - external tools - Go’s vuln system (only for Go modules) - GitHub advisories (platform-specific) Git should have had this **natively**. --- # ⭐ 5. **Built-In Fork Synchronization** Git should have supported: ### ✔ Automatic upstream tracking ### ✔ Automatic upstream diffing ### ✔ Automatic upstream merge suggestions ### ✔ Automatic conflict detection ### ✔ Automatic patch propagation Instead, we have: - manual remotes - manual fetch - manual merge - manual conflict resolution Git should have had a **first-class fork model**. --- # ⭐ 6. **Built-In Repository Renaming Without Breaking Imports** Git should have supported: ### ✔ Stable repository identity ### ✔ Stable import identity ### ✔ Stable module identity ### ✔ Renames without breakage ### ✔ Moves without breakage ### ✔ Aliases Instead, Go import paths break if: - the repo moves - the user changes their username - the repo is renamed - the platform changes - the domain changes Git should have had **stable identity**, not “URL = identity”. --- # ⭐ 7. **Built-In Multi-Repo Project Support** Git should have supported: ### ✔ Multi-repo projects ### ✔ Multi-repo manifests ### ✔ Multi-repo versioning ### ✔ Multi-repo snapshots ### ✔ Multi-repo reproducibility Instead, we have: - submodules (broken) - subtrees (hacky) - monorepos (workaround) - external tools (Bazel, Buck, Pants) Git should have had **native multi-repo support**. --- # ⭐ 8. **Built-In Metadata Files for Remote Code** Git should have supported: ### ✔ `.gitorigin` Stores original upstream URL. ### ✔ `.gitpurpose` Stores why the repo exists. ### ✔ `.gitfork` Stores fork lineage. ### ✔ `.gitsecurity` Stores security metadata. ### ✔ `.gitdeps` Stores dependency graph. Instead, we have: - nothing - manual text files - tribal knowledge Git should have had **first-class metadata**. --- # ⭐ 9. **Built-In Import Path Abstraction** Git should have supported: ### ✔ Clean import names ### ✔ Semantic import names ### ✔ Import aliases ### ✔ Import remapping ### ✔ Import rewriting Without breaking: - security scanning - module identity - provenance Instead, languages like Go embed garbage URLs into source code. Git should have provided a **clean abstraction layer**. --- # ⭐ 10. **Built-In Reproducible Snapshots** Git should have supported: ### ✔ Project-level snapshots ### ✔ Dependency snapshots ### ✔ Multi-repo snapshots ### ✔ Build snapshots ### ✔ Environment snapshots Instead, reproducibility is: - manual - fragile - external - inconsistent Git should have had **snapshot manifests**. --- # ⭐ FINAL SUMMARY — WHAT GIT SHOULD HAVE BEEN Git should have included: 1. **Dependency manifest system** 2. **Lockfile system** 3. **Semantic versioning** 4. **Provenance tracking** 5. **Security metadata** 6. **Fork synchronization** 7. **Stable repository identity** 8. **Multi-repo project support** 9. **Import path abstraction** 10. **Reproducible snapshots** If Git had these features, you would NOT be suffering: - meaningless import paths - dependency chaos - submodule hell - lost provenance - broken security scanning - non-future-proof naming - manual patch tracking - manual manifest creation - manual Delphi porting Git is brilliant — but incomplete. *** 222 RFC/PROPOSAL SECTION: *** --- # **RFC: Proposal for Enhancing Git with First-Class Dependency, Provenance, and Security Metadata** --- ## **1. Introduction** Git is exceptionally strong as a distributed version-control system, but modern software development increasingly relies on: - multi-repository architectures - dependency graphs - reproducible builds - long-term provenance - fork synchronization - security metadata - stable module identities These requirements are now fundamental to large-scale software engineering, yet Git provides no native mechanisms for them. As a result, ecosystems (Go, Rust, npm, Cargo, Maven, etc.) have built their own parallel systems on top of Git to compensate for missing features. This RFC proposes a set of enhancements that would allow Git to natively support these modern workflows. --- ## **2. Problem Statement** Git repositories today lack: 1. **Dependency manifests** 2. **Dependency lockfiles** 3. **Provenance metadata** 4. **Fork lineage tracking** 5. **Stable repository identity independent of URL** 6. **Security advisory integration** 7. **Multi-repository project support** 8. **Import path abstraction** 9. **Reproducible multi-repo snapshots** These gaps force developers to rely on: - ad-hoc conventions - external package managers - fragile submodules - undocumented local remotes - manual patch tracking - URL-encoded identities - platform-specific metadata (GitHub/GitLab) This creates long-term maintainability issues, especially when: - repositories are renamed - maintainers disappear - URLs change - forks diverge - security advisories are issued - dependency graphs grow large Git’s current feature set is insufficient for these realities. --- ## **3. Proposed Features** ### **3.1. First-Class Dependency Manifest** Introduce a repository-level file: ˋˋˋ .gitdeps ˋˋˋ Containing: - dependency name - dependency URL - dependency version or commit - purpose/description - license metadata This would be analogous to: - go.mod - Cargo.toml - package.json - Maven pom.xml but standardized at the Git level. --- ### **3.2. Dependency Lockfile** Introduce: ˋˋˋ .gitdeps.lock ˋˋˋ Containing: - exact commit hashes - integrity hashes - reproducible snapshot metadata This enables deterministic builds across machines and time. --- ### **3.3. Provenance Metadata** Introduce: ˋˋˋ .gitorigin ˋˋˋ Containing: - original upstream URL - fork lineage - migration history - repository identity (stable UUID) This prevents loss of provenance when: - remotes are removed - repositories are renamed - repositories move between hosts --- ### **3.4. Stable Repository Identity** Introduce a **repository UUID** stored in `.git/identity`. This would allow: - renaming - moving - mirroring - hosting changes without breaking: - import paths - dependency manifests - security metadata - tooling This solves the long-standing problem of “URL = identity”. --- ### **3.5. Security Metadata Integration** Introduce: ˋˋˋ .gitsecurity ˋˋˋ Containing: - CVE metadata - advisory links - affected versions - patched versions - severity This allows Git to: - warn on checkout - warn on merge - warn on dependency resolution without relying on external platforms. --- ### **3.6. Fork Synchronization Metadata** Introduce: ˋˋˋ .gitfork ˋˋˋ Containing: - upstream URL - last synced commit - divergence metadata - pending upstream changes This enables: - automated fork synchronization - upstream diffing - patch propagation --- ### **3.7. Multi-Repository Project Support** Introduce: ˋˋˋ .gitproject ˋˋˋ Containing: - list of repositories - versions/commits - dependency graph - snapshot ID This replaces: - submodules - subtrees - monorepo hacks - external build systems with a native Git solution. --- ### **3.8. Import Path Abstraction Layer** Introduce: ˋˋˋ .gitimports ˋˋˋ Mapping: - clean semantic names → repository identities - repository identities → URLs This allows: - renaming repositories - moving repositories - reorganizing namespaces without breaking source code. --- ### **3.9. Reproducible Multi-Repo Snapshots** Introduce: ˋˋˋ .gitproject.lock ˋˋˋ Containing: - exact commits for all repos - integrity hashes - dependency graph hash This enables: - reproducible builds - reproducible CI - reproducible releases across multi-repo systems. --- ## **4. Backward Compatibility** All proposed files: - are optional - do not affect existing Git behavior - do not break existing repositories - can be ignored by older Git versions - can be adopted incrementally This ensures safe adoption. --- ## **5. Benefits** ### **For developers** - stable naming - reproducible builds - long-term maintainability - clear provenance - easier forking - easier patch tracking ### **For large organizations** - multi-repo project management - compliance and auditability - security integration - deterministic builds ### **For ecosystems** - no need to reinvent dependency systems - no need to encode URLs into source code - no need for fragile submodules --- ## **6. Conclusion** Git is an exceptional version-control system, but modern software development requires features that Git does not currently provide. This RFC proposes a set of optional, backward-compatible extensions that would allow Git to evolve into a complete, future-proof foundation for multi-repository, dependency-driven development. I welcome discussion, critique, and refinement of these ideas. **— Harald Houppermans** --- If you want, I can also prepare: - a shorter version - a more formal academic-style version - a version targeted at GitHub/GitLab instead of Git itself - a version with diagrams and examples *** 333 EXAMPLE SECTION *** --- # **RFC (with Examples): Enhancing Git with First-Class Dependency, Provenance, and Security Metadata** **From:** Harald Houppermans **Subject:** RFC (with Examples): Missing Git Features for Modern Multi-Repository Development **To:** git@vger.kernel.org **Date:** (fill in) --- ## **1. Introduction** Modern software development relies heavily on: - multi-repository dependency graphs - reproducible builds - long-term provenance - fork synchronization - security advisories - stable module identities Git provides none of these natively. This RFC illustrates the missing features using **real examples** from common workflows. --- # **2. Problems Illustrated with Real Examples** ## **2.1. Missing Dependency Manifest** ### **Example Problem** A project depends on 40+ upstream repositories: ˋˋˋ github.com/go-yaml/yaml github.com/pelletier/go-toml golang.org/x/crypto github.com/stretchr/testify ˋˋˋ Git has **no way** to record: - why these dependencies exist - which versions are required - which commits were used - how they relate to each other Developers must rely on: - ad-hoc documentation - external package managers - fragile submodules ### **Proposed Solution** Introduce: ˋˋˋ .gitdeps ˋˋˋ Example: ˋˋˋ [yaml] url = "https://github.com/go-yaml/yaml" commit = "a3f1234" purpose = "YAML parsing" [toml] url = "https://github.com/pelletier/go-toml" commit = "b7c9812" purpose = "TOML configuration" ˋˋˋ --- ## **2.2. Missing Lockfile for Reproducible Builds** ### **Example Problem** Two developers clone the same project. One gets dependency commit A, the other gets commit B. Builds differ. Bugs differ. Security exposure differs. ### **Proposed Solution** Introduce: ˋˋˋ .gitdeps.lock ˋˋˋ Example: ˋˋˋ yaml = "a3f1234" toml = "b7c9812" crypto = "c9d8123" ˋˋˋ This ensures **deterministic builds**. --- ## **2.3. Missing Provenance Metadata** ### **Example Problem** A forked repository loses its upstream information: ˋˋˋ git remote add upstream ... ˋˋˋ This is **local only**. Once pushed to GitHub/GitLab, provenance is lost. ### **Proposed Solution** Introduce: ˋˋˋ .gitorigin ˋˋˋ Example: ˋˋˋ origin = "https://github.com/go-yaml/yaml" forked_by = "Skybuck" reason = "Long-term maintenance + reproducibility" ˋˋˋ This metadata travels with the repository. --- ## **2.4. Missing Stable Repository Identity** ### **Example Problem** If a repository is renamed: ˋˋˋ github.com/user1/yaml → github.com/user2/yaml ˋˋˋ All import paths break. All tooling breaks. All downstream forks break. Git treats the URL as the identity. ### **Proposed Solution** Introduce a stable repository UUID: ˋˋˋ .git/identity uuid = "d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ URLs can change; identity remains stable. --- ## **2.5. Missing Security Metadata** ### **Example Problem** A dependency has a CVE: ˋˋˋ CVE-2022-28948 in go-yaml/yaml ˋˋˋ Git has no way to: - warn on checkout - warn on merge - warn on dependency resolution ### **Proposed Solution** Introduce: ˋˋˋ .gitsecurity ˋˋˋ Example: ˋˋˋ [yaml] cve = ["CVE-2022-28948"] fixed_in = "v3.0.1" severity = "high" ˋˋˋ Git could warn: > “Warning: dependency yaml@a3f1234 contains known vulnerabilities.” --- ## **2.6. Missing Fork Synchronization Metadata** ### **Example Problem** A fork diverges from upstream. There is no built-in way to track: - last upstream sync - pending upstream commits - divergence depth ### **Proposed Solution** Introduce: ˋˋˋ .gitfork ˋˋˋ Example: ˋˋˋ upstream = "https://github.com/go-yaml/yaml" last_synced = "a3f1234" pending_commits = 12 ˋˋˋ --- ## **2.7. Missing Multi-Repository Project Support** ### **Example Problem** A project consists of 20 repositories. Git submodules are: - fragile - drift-prone - hard to clone - hard to update - hard to audit ### **Proposed Solution** Introduce: ˋˋˋ .gitproject ˋˋˋ Example: ˋˋˋ repos = [ "core", "parser", "crypto", "network", "ui" ] ˋˋˋ And a lockfile: ˋˋˋ .gitproject.lock core = "a1b2c3" parser = "d4e5f6" crypto = "112233" ˋˋˋ This enables **reproducible multi-repo snapshots**. --- ## **2.8. Missing Import Path Abstraction** ### **Example Problem** Languages like Go embed URLs directly into source code: ˋˋˋ import "github.com/go-yaml/yaml" ˋˋˋ If the repo moves or is renamed, the code breaks. ### **Proposed Solution** Introduce: ˋˋˋ .gitimports ˋˋˋ Example: ˋˋˋ sky/yaml = "uuid:d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ Source code imports: ˋˋˋ import "sky/yaml" ˋˋˋ Git resolves it via the identity mapping. --- # **3. Summary of Proposed Files** | File | Purpose | |------|---------| | `.gitdeps` | Dependency manifest | | `.gitdeps.lock` | Reproducible dependency snapshot | | `.gitorigin` | Provenance metadata | | `.gitsecurity` | Security advisories | | `.gitfork` | Fork synchronization metadata | | `.gitproject` | Multi-repo project definition | | `.gitproject.lock` | Multi-repo snapshot | | `.gitimports` | Import path abstraction | All files are: - optional - backward-compatible - non-breaking - easy to adopt incrementally --- # **4. Conclusion** These examples demonstrate that Git lacks several features required for modern multi-repository, dependency-driven development. The proposed metadata files and identity mechanisms would significantly improve: - reproducibility - provenance - security - maintainability - long-term stability I welcome discussion and refinement. **— Harald Houppermans** Bye for now, Skybuck Flying/Harald Houppermans ! ;) =D XD ``` ## Skybuck Flying, 2026-06-01 21:32 Subject: Re: Missing Git Features for Modern Multi-Repository, Dependency-Driven Development Message-ID: In-Reply-To: ``` Point 7 needs further explaining and this document will do so: 7. **Stable repository identity** --- # ⭐ **SPECIFICATION: Stable Repository Identity for Git** Modern software projects increasingly rely on large dependency graphs, multi‑repository structures, reproducible builds, and long‑term provenance. Git provides excellent version control but lacks native mechanisms for these workflows. This specification outlines optional, backward‑compatible metadata extensions that would allow Git to better support modern development practices. This document contains four sections: 111. WHAT GIT SHOULD HAVE BEEN 222. RFC / PROPOSAL 333. IMPLEMENTATION IDEAS / DETAILS 444. EXAMPLES --- # ⭐ **111. WHAT GIT SHOULD HAVE BEEN — Stable Repository Identity** Git is brilliant at what it was designed for: - content‑addressable storage - distributed history - immutable snapshots But Git has one deep architectural flaw: > **A repository’s identity = its URL.** This has caused 15+ years of breakage across ecosystems: - Go import paths break when repos move - mirrors confuse tooling - forks lose provenance - dependency manifests rot - security advisories become invalid - organizational migrations break everything - renames break imports and builds Git treats the *transport location* as the *identity*. This is backwards. --- ## ⭐ **Basic Idea (3–5 lines)** Git breaks when a repository’s URL changes because the URL *is* the identity. The fix is to give every repo a permanent UUID stored in `.git/identity`. Tools then import using a stable name like `sky/yaml`, which Git maps to the UUID. If the repo moves, renames, or changes hosting, only the mapping updates — **the code stays the same**. --- Git should have had: ### ✔ A stable, permanent identity ### ✔ Independent of URL ### ✔ Independent of hosting provider ### ✔ Independent of username ### ✔ Independent of organization ### ✔ Independent of mirrors and forks This identity should have been: - generated once - stored inside the repo - immutable - portable - cryptographically strong Something like: ˋˋˋ .git/identity uuid = "d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ This would have allowed: - renaming - moving - mirroring - forking - reorganizing - migrating hosts **without breaking anything.** Git should have been built on **stable identity**, not URLs. --- # ⭐ **222. RFC: Stable Repository Identity for Git** ## **1. Introduction** Git repositories today are identified by their URLs. This creates long‑term fragility in: - dependency management - import paths - provenance tracking - fork lineage - security metadata - multi‑repo systems - organizational migrations This RFC proposes a minimal, optional, backward‑compatible mechanism for assigning **stable identities** to Git repositories. --- ## **2. Problem Statement** Git currently lacks: - a persistent repository identity - a way to track renames - a way to track hosting moves - a way to track mirrors - a way to track forks - a way to track upstream provenance - a way to reference repositories independent of URLs As a result: - Go import paths break - dependency manifests rot - security advisories become invalid - forks lose their origin - mirrors cannot be recognized - tools cannot detect duplicates - organizations cannot reorganize safely Git’s URL‑based identity model is insufficient for modern software engineering. --- ## **3. Proposed Feature: `.git/identity`** Introduce a file: ˋˋˋ .git/identity ˋˋˋ Containing: ˋˋˋ uuid = "<128-bit UUID>" ˋˋˋ ### **Properties** - generated once at `git init` - immutable - portable - stored inside the repository - independent of hosting - independent of remotes - independent of URLs - independent of usernames ### **Benefits** - stable identity across renames - stable identity across mirrors - stable identity across forks - stable identity across hosting providers - stable identity across organizational changes --- ## **4. Use Cases** ### **4.1. Import Path Stability** Tools and languages can reference: ˋˋˋ uuid:d8f1-9c2e-44b1-8f3a-abc123 ˋˋˋ instead of: ˋˋˋ github.com/user/project ˋˋˋ Renames no longer break imports. --- ### **4.2. Dependency Manifest Stability** Manifests can store: ˋˋˋ yaml = "uuid:d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ instead of URLs. This prevents dependency rot. --- ### **4.3. Provenance Tracking** Forks can store: ˋˋˋ origin_uuid = "d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ Git can detect: - upstream - divergence - last sync - fork lineage --- ### **4.4. Security Metadata Stability** Security advisories can reference UUIDs instead of URLs. This prevents advisories from breaking when repos move. --- ## **5. Backward Compatibility** - optional - ignored by older Git versions - does not affect existing workflows - does not change commit formats - does not change remotes - does not change URLs - does not break anything --- ## **6. Conclusion** A stable repository identity is a minimal, optional enhancement that solves long‑standing structural issues in Git’s architecture. It enables robust dependency management, provenance tracking, security metadata, and multi‑repo tooling. --- # ⭐ **333. IMPLEMENTATION IDEAS / DETAILS** This section describes how hosting providers (GitHub, GitLab, Gitea, Bitbucket, self‑hosted servers) could implement and expose stable repository identities using the proposed `.git/identity` file. --- ## **3.1. Repository UUID Storage** When a repository is pushed, the hosting provider reads: ˋˋˋ .git/identity uuid = "<128-bit UUID>" ˋˋˋ The platform stores this UUID in its internal metadata database. If the file does not exist, the platform may: - generate a UUID on first push, or - leave the field empty (backward compatibility) --- ## **3.2. URL Structure and Access** ### **Human‑friendly URLs remain unchanged** ˋˋˋ https://github.com/SkybuckFlying/yaml https://gitlab.com/sky/yaml ˋˋˋ ### **Optional UUID‑based URLs** ˋˋˋ https://github.com/uuid/d8f1-9c2e-44b1-8f3a-abc123 https://gitlab.com/uuid/d8f1-9c2e-44b1-8f3a-abc123 ˋˋˋ These URLs: - never change - always resolve to the current location - survive renames, moves, and hosting migrations --- ## **3.3. Redirect Behavior** If a repository is renamed: ˋˋˋ /yaml → /yaml2 ˋˋˋ UUID URL still works. If moved to another user or organization: ˋˋˋ /SkybuckFlying/yaml → /sky-org/yaml ˋˋˋ UUID URL still works. If moved to another hosting provider: ˋˋˋ github → gitlab ˋˋˋ UUID URL still works. --- ## **3.4. Fork and Mirror Detection** With UUIDs, platforms can detect: - mirrors (same UUID, same commit graph) - forks (different UUID, but `.gitorigin` references parent UUID) - duplicates (same UUID, different URLs) This enables: - accurate fork lineage - upstream tracking - divergence analysis - provenance reconstruction --- ## **3.5. Cloning by UUID** Git could support: ˋˋˋ git clone uuid:d8f1-9c2e-44b1-8f3a-abc123 ˋˋˋ Git resolves the UUID by: - checking `.gitimports` - checking local registry - querying hosting providers - falling back to known mirrors --- ## **3.6. Dependency Resolution Using UUIDs** Manifests can reference UUIDs: ˋˋˋ yaml = "uuid:d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ Tools resolve the UUID to a URL using: - `.gitimports` - hosting provider lookup - local cache This prevents dependency rot. --- ## **3.7. Security Metadata Integration** Security advisories can reference UUIDs: ˋˋˋ uuid = "d8f1-9c2e-44b1-8f3a-abc123" cve = ["CVE-2022-28948"] ˋˋˋ Platforms can warn users when: - cloning vulnerable repos - checking out vulnerable commits --- ## **3.8. Backward Compatibility** - Repositories without `.git/identity` continue to work - Tools ignoring UUIDs continue to work - URLs remain unchanged - No protocol changes - No breaking changes --- # ⭐ **444. EXAMPLES — Why Stable Identity Matters** ## **Example 1: Go Import Path Breakage** Today: ˋˋˋ import "github.com/user1/yaml" ˋˋˋ User renames account → imports break. With UUIDs: ˋˋˋ import "sky/yaml" ˋˋˋ Mapped via: ˋˋˋ sky/yaml = "uuid:d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ Repo moves → nothing breaks. --- ## **Example 2: Fork Provenance Loss** Today Git does not know: - what repo a fork came from - when it was last synced - how far it diverged With UUIDs: ˋˋˋ .gitorigin origin_uuid = "d8f1-9c2e-44b1-8f3a-abc123" last_synced = "a3f1234" ˋˋˋ Git can track upstream properly. --- ## **Example 3: Security Advisory Stability** Today advisories reference URLs: ˋˋˋ CVE-2022-28948 affects github.com/user/yaml ˋˋˋ Repo moves → advisory becomes ambiguous. With UUIDs: ˋˋˋ uuid = "d8f1-9c2e-44b1-8f3a-abc123" cve = ["CVE-2022-28948"] ˋˋˋ Advisory remains valid forever. --- ## **Example 4: Organizational Migration** Company moves from GitHub → GitLab. Today: - all URLs change - manifests break - imports break - tooling breaks With UUIDs: - identity stays the same - manifests stay valid - imports stay valid - tooling stays valid Only the URL mapping changes. --- ## **Example 5: Mirror Detection** Today Git cannot tell: - if two URLs point to the same repo - if a repo is a mirror - if a repo is a duplicate With UUIDs: ˋˋˋ uuid = "d8f1-9c2e-44b1-8f3a-abc123" ˋˋˋ Git instantly knows: > “These two repos are the same project.” --- Bye for now, Skybuck Flying / Harald Houppermans ! ;) =D XD ``` ## Skybuck Flying, 2026-06-01 21:48 Subject: Re: Missing Git Features for Modern Multi-Repository, Dependency-Driven Development Message-ID: In-Reply-To: ``` Point ⭐ 3. **Built-In Provenance Tracking** Sub Point: Fork lineage  ^ Also needs some further clarification, here is: --- # ⭐ **SPECIFICATION: Built‑In Provenance Tracking for Git (Enhanced Edition)** Modern software development depends on understanding where code comes from, how it evolves, and how repositories relate to each other. Git tracks commits, but it does **not** track repositories. This leaves a massive blind spot in provenance, security, and multi‑repo tooling. This document proposes a minimal, backward‑compatible metadata system that gives Git true repository‑level lineage and multi‑generation fork divergence tracking. Sections: 111. WHAT GIT SHOULD HAVE BEEN 222. RFC / PROPOSAL 333. IMPLEMENTATION DETAILS 444. EXAMPLES --- # ⭐ **111. WHAT GIT SHOULD HAVE BEEN — Provenance Tracking** Git is excellent at tracking *content*, but it is completely blind to *where repositories come from*. This leads to long‑standing problems: - forks lose their origin - mirrors cannot be detected - renames erase history - hosting migrations break lineage - dependency tools cannot trace ancestry - security tools cannot identify upstream - multi‑repo systems cannot reason about relationships Git treats every clone as an isolated universe. That is fundamentally wrong. Git should have tracked: ### ✔ Original upstream ### ✔ Fork lineage ### ✔ Migration history ### ✔ Renames ### ✔ Moves ### ✔ Repository identity --- ## ⭐ **Basic Idea (3–5 lines)** Every repository has a UUID. Every fork stores the UUID of the repo it was forked from. That parent does **not** need to be the true origin — it can be a fork of a fork. Git walks these UUID links to reconstruct the entire ancestry chain. This gives Git real provenance for the first time. --- Git should have been able to answer: - “Where did this repo come from.” - “What is its upstream.” - “How many generations deep is this fork.” - “How far behind upstream is it — at every level.” - “What is the full lineage tree.” Today Git cannot answer any of these. --- # ⭐ **222. RFC: Provenance Metadata for Git** ## **1. Introduction** Git repositories lack built‑in provenance metadata. This prevents Git from understanding: - fork relationships - upstream lineage - migration history - renames and moves - mirrors - divergence depth This RFC proposes a minimal, optional metadata file that records a repository’s **parent identity** and **last upstream sync**. --- ## **2. Problem Statement** Git currently cannot: - detect forks - detect mirrors - detect renames - detect hosting migrations - compute fork depth - compute divergence from upstream - reconstruct ancestry - track provenance across platforms This causes: - lost history - broken tooling - ambiguous security metadata - dependency confusion - inability to reason about multi‑repo graphs --- ## **3. Proposed Feature: `.gitorigin`** Introduce a file: ˋˋˋ .gitorigin ˋˋˋ Containing: ˋˋˋ origin_uuid = "" last_synced = "" ˋˋˋ ### **Properties** - stored in the repo - points to the repo this one was forked from - parent does NOT need to be the true origin - supports multi‑generation fork chains - supports migration history - supports renames and moves - supports mirrors ### **Benefits** - Git can reconstruct full lineage - Git can compute divergence - Git can detect mirrors - Git can detect lost forks - Git can track upstream sync - Git can show ancestry trees - Git can support provenance‑aware tooling --- ## **4. Relationship to `.git/identity`** Each repo has: ˋˋˋ .git/identity uuid = "" ˋˋˋ Each fork has: ˋˋˋ .gitorigin origin_uuid = "" ˋˋˋ Together, these form a **repository‑level DAG**. --- # ⭐ **333. IMPLEMENTATION DETAILS (Enhanced)** This section describes how Git and hosting providers can implement fork lineage tracking — including the part you found most impressive: > **Git can compute “commits behind” for every fork in the chain.** --- ## **3.1. Fork Creation** When a user forks a repo: 1. The new repo generates its own UUID 2. The new repo writes: ˋˋˋ .gitorigin origin_uuid = "" last_synced = "" ˋˋˋ This works even if: - the parent is itself a fork - the parent is a mirror - the parent has moved hosts - the parent has been renamed --- ## ⭐ **3.2. Multi‑Generation Fork Chains WITH Divergence Tracking** Let’s illustrate this clearly. ### **Repository chain:** ˋˋˋ Origin (O) ↓ forked by Fork A (A) ↓ forked by Fork B (B) ↓ forked by Fork C (C) ˋˋˋ ### **Commit history:** ˋˋˋ Origin: 100 commits Fork A: +5 commits (105 total) Fork B: +3 commits (108 total) Fork C: +7 commits (115 total) ˋˋˋ ### **Upstream sync points:** Fork A synced at commit 100 Fork B synced at commit 105 Fork C synced at commit 108 ### **Git can compute:** #### **Fork A** - Ahead of Origin: +5 - Behind Origin: 0 #### **Fork B** - Ahead of A: +3 - Behind A: 0 - Behind Origin: 5 #### **Fork C** - Ahead of B: +7 - Behind B: 0 - Behind A: 3 - Behind Origin: 8 Git can now show: ˋˋˋ C is 7 commits ahead of B C is 3 commits behind A C is 8 commits behind Origin ˋˋˋ This is the part you loved — and yes, it’s absolutely possible. --- ## **3.3. Migration History** If a repo moves: - GitHub → GitLab - user → organization - mirror → new host The UUID stays the same. The `.gitorigin` stays the same. Lineage is preserved. --- ## **3.4. Mirror Detection** If two repos share the same UUID: ˋˋˋ uuid = X uuid = X ˋˋˋ They are mirrors. Git can warn: > “These repositories are identical mirrors.” --- ## **3.5. Lost Fork Recovery** If someone clones a fork and pushes it elsewhere: Git can still detect: > “This repo is a descendant of O.” Because the `.gitorigin` chain is intact. --- ## **3.6. Backward Compatibility** - Repos without `.gitorigin` behave normally - Tools ignoring provenance behave normally - No protocol changes - No breaking changes This is purely additive. --- # ⭐ **444. EXAMPLES — Fork Lineage in Practice (Enhanced)** ## **Example 1: Fork → Fork → Fork with Divergence** ˋˋˋ Origin → Fork A → Fork B → Fork C ˋˋˋ Git reconstructs: ˋˋˋ C → B → A → Origin ˋˋˋ Git computes: ˋˋˋ C is 7 ahead of B C is 3 behind A C is 8 behind Origin ˋˋˋ This is impossible today. --- ## **Example 2: Fork Becomes the New Upstream** Origin is abandoned. Fork B becomes the new mainline. Fork C updates: ˋˋˋ origin_uuid = B ˋˋˋ Git still knows: ˋˋˋ C → B → A → Origin ˋˋˋ This is migration history. --- ## **Example 3: Mirror Detection** Two repos have the same UUID: ˋˋˋ uuid = "abc" uuid = "abc" ˋˋˋ Git knows: > “These are mirrors.” --- ## **Example 4: Hosting Migration** Repo moves: ˋˋˋ github.com/user/yaml → gitlab.com/sky/yaml ˋˋˋ UUID stays the same. `.gitorigin` stays the same. Lineage stays intact. --- ## **Example 5: Lost Fork Recovery** Someone clones Fork B and pushes it to a new host. Git reads: ˋˋˋ origin_uuid = A ˋˋˋ Git reconstructs: ˋˋˋ NewRepo → B → A → Origin ˋˋˋ Lineage recovered. --- Bye for now, Skybuck Flying / Harald Houppermans ! ;) =D XD ```