Re: [RFC] Adding a native, opt-in versioning system to Git (distinct from tags and branch names)

Further ideas/enhancements:

Subject: [RFC] Extending Git: Native Versioning, Enhanced Accountability, and Repository Health Primitives

Dear Git developers and contributors,

This proposal extends the concept of a first-class, opt-in versioning mechanism (as previously discussed) to address two related architectural concerns frequently raised by larger development teams and security-conscious environments: Accountability and Repository Redundancy.
________________________________________
1. Core Feature: Native Versioning (Recap & Enhancement)
Git is a content-addressable history tracker, but it lacks a standardized, machine-readable version primitive independent of tags and SHA-1 hashes.
Proposed Feature:
Introduce an opt-in versioning subsystem that allows every commit to carry an explicit version identifier. This version should be treated as mutable metadata that survives operations like rebase unless explicitly changed.
Enhanced Version Structure (Addressing Accountability):
To maximize clarity, auditing, and trust, especially in projects with many contributors or automated commits (AI/bots), the versioning format should explicitly support encoding the commit author or base ref. This moves beyond basic SemVer to the more information-rich structure discussed in Text 1:
$$\text{Version Identifier} \approx \langle \text{Base Version}\rangle \text{-} \langle \text{Author/Branch Identifier}\rangle \text{-} \langle \text{Sub-Version}\rangle$$
Example format (custom): 0.0004-SKYBUCK-MASTER-0.001-SUB-FEATURE
Rationale: Provides instant clarity on the lineage and authorship of the base commit, which is crucial for auditing and accountability—addressing the security concerns around dependencies and supply-chain attacks.
Storage Direction:
Continue exploring adding a Version: header to the commit object, allowing the version to travel with the commit object itself.
________________________________________
2. Feature: Repository Redundancy and Health
Git's current design relies on local copies for redundancy. A single-bit error in a repository's object database (for a clone that is not regularly re-fetched) can render the local copy unusable, requiring manual re-cloning or repair.
Proposed Feature:
Introduce a primitive mechanism for internal repository health and redundancy tracking. This would focus on protecting the Git repository structure itself, not just the checked-out source code (which worktrees address).
Initial Idea (Addressing Redundancy):
Repo Pointer/Reference: Introduce an optional, well-known, trackable reference (e.g., refs/repo/latest) that points to a verified, redundant copy of the repository (or the most recent successful backup/mirror).
Self-Verification Command: A new command, git verify-integrity --redundancy, could check the integrity of the current repo and compare it against the health status of the repo referenced by the pointer.
Rationale: This would standardize the process of managing redundant repository copies, making recovery from corruption easier and more automated than relying on manual, ad-hoc copying.
________________________________________
3. Feature: Improved Branch Visualization Metadata
While external tools handle visualization, Git's structure can be enhanced to support a clearer timeline view, addressing the issue where history is hard to follow, and commits can appear non-chronologically.
Proposed Metadata Enhancement:
If the native versioning system is adopted, visualization tools should prioritize the sequential version number as the primary ordering key, falling back to chronological commit date only when versions are identical. This would help counteract the common visualization problem where older commits can appear above newer ones due to branch/merge complexity, allowing users to "Respect the flow of time" as defined by the deliberate version progression.
________________________________________
Conclusion
This expanded proposal seeks to enhance Git's capabilities by standardizing versioning (using an accountability-focused structure) and introducing primitives for redundancy checking, leveraging the new version data to also improve visualization. The features remain completely opt-in and do not affect existing workflows.

Best regards, Skybuck Flying November 17, 2025