From: Skybuck Flying Date: Mon, 01 Jun 2026 20:57:55 GMT 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