Missing Git Features for Modern Multi-Repository, Dependency-Driven Development

From: Skybuck Flying <skybuck2000@hotmail.com>
Date: Jun 1, 2026, 20:57 UTC
Message-ID: <AM0PR02MB4450F6AF2F662C51F3145B48B3152@AM0PR02MB4450.eurprd02.prod.outlook.com>

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