Tbh this sounds like a solution in search of a problem. Ain’t nobody got time to learn some new workflow with associated helper scripts which in the end provide questionable value, if any at all.
If working with queues of patches on a trunk based workflow is your jam then try Gerrit
That is actually one of the main points of Git Patch Stack. Gerrit which does support a trunk based workflow of patches similarly. It however requires a completely new set of tooling both on the client and the server side of things. So your team needs to switch to a different SCM platform which isn’t GitHub, GitLab, or Bitbucket, etc. Which means adoption requires an entire team to do a massive switch.
Git Patch Stack on the other hand provides the trunk based workflow while still allowing the user to use Git however they might want, and also interact with the feature branch/pull request model of GitHub, Bitbucket, GitLab, etc. So each dev can locally do what makes sense for them rather than having to get entire team to migrate over to something like Gerrit. Also it doesn’t have any additional state creation. It just provides a meaningful view of the Git tree in a way that makes sense for the trunk based workflow, as well as additional commands to make operating conceptually in that world make more sense. So it makes it easy for people to have hybrid workflows or adopt the workflow over time, etc.
Tbh this sounds like a solution in search of a problem. Ain’t nobody got time to learn some new workflow with associated helper scripts which in the end provide questionable value, if any at all.
If working with queues of patches on a trunk based workflow is your jam then try Gerrit
That is actually one of the main points of Git Patch Stack. Gerrit which does support a trunk based workflow of patches similarly. It however requires a completely new set of tooling both on the client and the server side of things. So your team needs to switch to a different SCM platform which isn’t GitHub, GitLab, or Bitbucket, etc. Which means adoption requires an entire team to do a massive switch.
Git Patch Stack on the other hand provides the trunk based workflow while still allowing the user to use Git however they might want, and also interact with the feature branch/pull request model of GitHub, Bitbucket, GitLab, etc. So each dev can locally do what makes sense for them rather than having to get entire team to migrate over to something like Gerrit. Also it doesn’t have any additional state creation. It just provides a meaningful view of the Git tree in a way that makes sense for the trunk based workflow, as well as additional commands to make operating conceptually in that world make more sense. So it makes it easy for people to have hybrid workflows or adopt the workflow over time, etc.