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