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

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.