Re: [RFC] Adding a native, opt-in versioning system to Git (distinct from tags and branch names)
- From
Skybuck Flying <skybuck2000@hotmail.com>
- Date
- Nov 17, 2025, 13:34 UTC
- Message-ID
- <AM0PR02MB44504C65BDF6C7D4B70652ECB3C9A@AM0PR02MB4450.eurprd02.prod.outlook.com>
- In-Reply-To
- <AM0PR02MB4450024F0F7380A5DE6B2006B3C9A@AM0PR02MB4450.eurprd02.prod.outlook.com>
### 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