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

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

Dear Git developers and contributors,

I’d like to start a focused discussion about whether Git could benefit from a first-class, **opt-in** versioning mechanism that is separate from the current tagging system and from human-readable branch names.

### Core observation Git is an extremely powerful content-addressable history tracker, but it deliberately does not provide built-in semantic or numeric versioning of commits or branches. Projects therefore reinvent versioning in many different ways (tags + git-describe, VERSION files, external tools, custom branch naming conventions, etc.). While these solutions work, they remain conventions rather than enforceable, machine-readable primitives.

### Proposed feature (high-level) Introduce an optional versioning subsystem that can be enabled per-repository (default: disabled) with configuration such as:

```ini
[version]
    enabled = false|true
    format  = decimal|semver|custom   ; e.g. 1.234 or 2025.11.17 or free-form
    auto-increment = none|patch|minor|master-only
```

When enabled, every new commit could carry an explicit, mutable version identifier that is **independent** of:

- the commit SHA-1  
- lightweight or annotated tags  
- branch names  

Possible technical directions (open for discussion):

1. Store the version in an extra header in the commit object  
   (`Version: 1.042`) – simple, visible in `git cat-file commit`, travels with the commit when pushed/pulled.

2. Maintain a dedicated ref namespace (`refs/version/HEAD` or `refs/version/<branch>`) that is updated automatically or via explicit commands.

3. A separate “version object” type linked from the commit.

New porcelain commands (all no-ops when the feature is disabled):

```sh git version            # show version of current commit, or “unversioned” git version bump [major|minor|patch|decimal]   # create new commit with incremented version git version set <v>    # explicitly set a version on a new commit ```

### Desired properties
- Completely optional and disabled by default – existing repositories and workflows are unaffected.  
- Orthogonal to tags (a commit can have both a tag v2.3.1 and an explicit version 2025.11.17).  
- Survives rebase, cherry-pick, amend, etc., unless explicitly changed.  
- Can be ignored by tools that do not understand it.  
- Allows projects to have a single source of truth for “what version am I looking at right now?” without parsing tags or running git-describe.

### Potential benefits
- Standardised, scriptable way to obtain the current version in builds, CI, packaging tools.  
- Easier generation of reproducible build artefacts and release notes.  
- Possibility to enforce version ordering or policies via hooks if desired.  
- Reduces the need for complex branch-naming conventions that try to encode version/author information.

### Questions for the list
1. Is there interest in adding such a native (but opt-in) versioning facility to Git core, or is the current ecosystem of tags + external tools considered sufficient?  
2. If there is interest, which storage approach would be least disruptive and most future-proof?  
3. Should automatic incrementing (e.g. “bump patch level on every commit to main”) be part of core, or left to porcelain / hooks?  
4. Are there strong objections (technical, philosophical, or maintenance-burden) to adding any form of mutable version metadata to commits?

This is deliberately an early RFC – no patch series yet – because the design space is large and community feedback will heavily influence whether this is worth pursuing.

Thank you for your time and thoughts.

Best regards,   Skybuck Flying   (The Netherlands)   November 17, 2025

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

### Subject: Proposal: Explicit Version Numbering and Visualization Improvements for Git

Hello all,

This text better represents the original observations/problems and ideas/solutions:

---

#### Problems with Git Today

1. **No explicit versioning**  
   Git relies on commit hashes, which are cryptographically strong but not human‑friendly. They don’t provide sequential order or readability, making it difficult to track progress.

2. **Branch complexity**  
   Branches often become outdated, leading to rebase/merge/delete cycles and confusing naming conventions. Developers end up inventing awkward branch names to avoid collisions.

3. **Redundancy concerns**  
   A single bit error in a `.git` database can corrupt the repository. While cloning provides some protection, Git lacks an internal redundancy pointer system to track the “latest valid copy.”

4. **Visualization issues**  
   Git log graphs are not strictly chronological. Commits can appear above newer ones, branches sprawl vertically, and shared branch names don’t align. This wastes time and makes history hard to follow.

---

#### Proposed Solution: Ultimate Gitflow

The core idea is **explicit version numbering for every commit and branch**, combined with author accountability and improved visualization.

- **Sequential version numbers on master**  
  Example:  
  ```
  0.0001-SKYBUCK-MASTER
  0.0002-SKYBUCK-MASTER
  0.0003-SKYBUCK-MASTER
  ```

- **Versioned sub‑branches**  
  Branches inherit the master version number and add their own sequence:  
  ```
  0.0004-SKYBUCK-MASTER-0.001-SKYBUCK-FEATURE
  ```

- **Recursive compact notation**  
  For deeply nested branches:  
  ```
  0.0004-0.001-0.001-0.001
  ```

- **Author tagging**  
  Each commit includes the author name in the version string, ensuring accountability and traceability.

- **Visualization aligned to version hierarchy**  
  Branches with the same name should align horizontally (“railroad track” style), reducing vertical clutter and making timelines clearer.

---

#### Benefits

- **Human readability**: Numbers and names are easier to scan than hashes.  
- **Accountability**: Author tags show who contributed what.  
- **Branch reuse**: Versioned names avoid collisions and stale references.  
- **Auditability**: Clear lineage of commits and branches, useful for security‑conscious projects.  
- **Flexibility**: Developers can define what counts as a “major” change, rather than being constrained by semantic versioning rules.

---

#### Implementation Path

- Git hooks or wrapper scripts to enforce numbering and tagging.  
- A custom visualization tool that parses commit messages/tags and renders branches as aligned tracks.  
- A redundancy layer that snapshots repositories and maintains a pointer to the latest valid copy.  
- Documentation of versioning philosophy, allowing developers to bump major numbers for breakthroughs (performance, robustness, efficiency), not just compatibility.

---

#### Closing Thoughts

Git’s flexibility is powerful, but it often leads to chaos in larger projects. By layering explicit version numbering, author accountability, and better visualization on top of Git, we can make history clearer, branches reusable, and repositories more resilient.

I’d be interested in hearing feedback from the community on whether this approach could be formalized into tooling or extensions around Git.

Best regards,   Skybuck Flying   17 November 2025  

Discussing how to implement this with external tools for git with Google gemini 2.5 ai:

The prompt:

" I want every commit on the master and sub branches to have their own version number. Plus author who created the commit, example for master branch for author Skybuck: For example: Commit1: version-0.01-Skybuck-Master Commit2: version-0.02-Skybuck-Master SubBranch for Skybuck Feature A: version-0.02-Skybuck-Master-sub-version-0.01-Skybuck-Feature-A Is it possible to implement this with external tools for git, or should the git source code itself be modified ? "

The ai answer/result so far:

" This versioning scheme is **possible to implement** using **external tools and Git hooks**, without needing to modify the Git source code itself. Modifying the Git source code is unnecessarily complex and not the standard way to enforce custom repository rules.

---

## 🛠️ Recommended Implementation Approach

The most practical way to enforce and generate this complex version string for every commit is by using **Git hooks** combined with a simple **scripting language** (like Python, Bash, or PowerShell).

### 1. Version Tracking Mechanism

You'll need a mechanism to track the next version number for the master branch (e.g., `0.01`, `0.02`) and the sub-branch (e.g., `0.01`, `0.02`).

* **Simplest Method (Recommended):** Store the next version number in a simple **text file** (e.g., `master_version.txt`) at the root of the repository. This file would be updated and committed *with* the changes, ensuring the version history is also tracked within the repository itself.
* **Alternative:** Use Git's **tagging** functionality to find the latest version number, but this is more complex to parse and manage, especially for the sub-branch numbers.

### 2. Git Hook Enforcement

The logic for generating and applying the version string should be placed in the **`prepare-commit-msg`** Git hook.

* **`prepare-commit-msg` Hook:** This hook runs right before the editor opens (or before the message is finalized if using `-m` or other options). It receives the path to the file containing the commit message.

### 3. Script Logic (Conceptual)

The script inside the hook would perform the following steps:

1.  **Determine Branch Type:** Check the current branch name (e.g., `git rev-parse --abbrev-ref HEAD`).
2.  **Identify Author:** Get the committer's name (e.g., `git config user.name`).
3.  **Calculate Master Version (`version-X.XX`):**
    * Read the current version from `master_version.txt`.
    * Increment the version (e.g., `0.01` $\rightarrow$ `0.02`).
4.  **Construct Base String (for any branch):**
    * `version-X.XX-Skybuck-Master`
5.  **Calculate Sub-Version (If on a Sub-Branch):**
    * If the current branch is **not** `master`, you need to calculate the sub-version. This is the tricky part. You would need a separate tracker (or a specific strategy) to find how many commits have been made on the sub-branch since it forked from the master branch.
    * A simple approach would be to maintain a sub-branch-specific version file (e.g., `sub_branch_A_version.txt`).
6.  **Construct Final Version String:**
    * **Master:** Append the calculated string to the beginning of the commit message.
    * **Sub-Branch:** Append the full string: `version-X.XX-Skybuck-Master-sub-version-Y.YY-Skybuck-Feature-A`
7.  **Update Version Files:** Increment and stage the relevant version tracking file(s) (`git add master_version.txt`). This ensures the next commit uses the correct, incremented version.

## ⚠️ Important Considerations

### A. Author Name

The author's name in your example (`Skybuck`) is static. Git can easily get the **actual committer's name** using `git config user.name`, which would make the system universal for all developers.

### B. Sub-Branch Complexity

Your sub-branch example is the hardest part: `version-0.02-Skybuck-Master-sub-version-0.01-Skybuck-Feature-A`.

* `version-0.02-Skybuck-Master`: This number must represent the **next version number the master branch *would have had*** if this commit was made on master. This requires checking the `master_version.txt` file as it exists on the **master branch** at the time the sub-branch was created, or more simply, checking the number on the parent commit's version.
* `sub-version-0.01`: This needs a counter specifically for the sub-branch's commits.

This degree of complexity is why most versioning tools (like **GitFlow** or **Semantic Versioning**) rely on **tags** applied to specific, important commits (like releases), rather than a unique version number for *every* single commit.

While technically possible, be prepared for this to be a **time-consuming script** to maintain and troubleshoot. "

I want to run this by you guys/the C programmers, maybe you can see a better way to do this than this AI/bot ???

Bye for now,
  Skybuck Flying.