git/list[1] front-page[2] threads[3] people[4] search[5] about
wed 2026-10-07 18:11 UTC

Re: Was "Re: [RFC] Proposed Git Workflow for Permanent History, Explicit Branch Status, and Developer Continuity" now "Skybuck's GitFlow"

From
Skybuck Flying <skybuck2000@hotmail.com>
Date
Nov 17, 2025, 14:37 UTC
Message-ID
<AM0PR02MB44504D0184E8EEFB7A80B98DB3C9A@AM0PR02MB4450.eurprd02.prod.outlook.com>
In-Reply-To
<AM0PR02MB4450BE9364544EE7ECE2CE13B3C9A@AM0PR02MB4450.eurprd02.prod.outlook.com>
Skybuck's GitFlow V5 has finally been released:
https://github.com/SkybuckFlying/Skybuck-s-Gitflow
https://github.com/SkybuckFlying/Skybuck-s-Gitflow/releases/tag/release-version-0.11
This newer version allows the remote repository to be specified so it's no longer limited to just "origin".
(I consider developing a new versioning system which is similar to this one, but where each commit is automatically versioned, this would make it even easier to re-use existing branch names which would fit git better).
I already posted a new topic about this. Something with opt-in versioning... RFC...

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

https://public-inbox.org/git/AM0PR02MB44504C65BDF6C7D4B70652ECB3C9A@AM0PR02MB4450.eurprd02.prod.outlook.com/T/#t
I am considering modifieing the GIT source code via AI to build in this feature. Another idea could be to  create external tools for git, as done for Skybuck's GitFlow.
Which path is followed depends on feasibility of external tools versus the need to build it into git itself.
I think I would prefer it build into git itself to solve this versioning problem once and for all and it makes more sense to re-use branch names.
Plus perhaps branch visualizer update so it respects time flow as well. Perhaps git can already do this with parameters, not sure.
Further notice:
This version/release 0.11 was done on 27 september(month 9) 2025, I just didn't have the time/energy to update the git repo etc.
Also version 0.11 was never properly tested but I did my best to give it a high chance of working.
I have also not yet had the chance to use it, struggling with gitflow/git itself, but getting close to a solution ;) plus BF6 major distraction too ! LOL XD
Bye for now,
  Skybuck.
Previous: Skybuck Flying
Message 15 of 15 in “[RFC] Proposed Git Workflow for Permanent History, Explicit Branch Status, and Developer Continuity”
  1. Skybuck FlyingJul 25, 2025
  2. Skybuck FlyingJul 25, 2025
  3. Skybuck FlyingJul 25, 2025
  4. Skybuck FlyingJul 25, 2025
  5. Skybuck FlyingJul 25, 2025
  6. Skybuck FlyingJul 25, 2025
  7. Skybuck FlyingJul 27, 2025
  8. SuperLaserC from LaserA and LaserB, continue LaserA/B fresh from SuperLaserC was Re: [RFC] Proposed Git Workflow for Permanent History, Explicit Branch Status, and Developer ContinuitySkybuck Flying, Jul 27, 2025
  9. Was "Re: [RFC] Proposed Git Workflow for Permanent History, Explicit Branch Status, and Developer Continuity" now "Skybuck's GitFlow"Skybuck Flying, Aug 29, 2025
  10. Skybuck FlyingAug 29, 2025
  11. Skybuck FlyingAug 31, 2025
  12. Skybuck FlyingAug 31, 2025
  13. Haridas MahatoSep 1, 2025
  14. Skybuck FlyingSep 5, 2025
  15. Skybuck FlyingNov 17, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.