From: Skybuck Flying Date: Mon, 17 Nov 2025 15:03:33 GMT Subject: Re: [RFC] Adding a native, opt-in versioning system to Git (distinct from tags and branch names) Message-ID: In-Reply-To: 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.