It has important ties to how the Linux Kernel and Git dev teams work as well as breaks down the benefits in relation to CI as a methodology.
I've been using stgit for a very long time, and before that, I used quilt, and before that, Andrew Morton's patch scripts. If I am not mistaken, Andrew Morton's patch scripts were the inspiration for quilt.
* https://stacked-git.github.io/ * https://linux.die.net/man/1/quilt * https://lkml.org/lkml/2002/10/20/149
This allows you to use the local Patch Stack style workflow similar to the Linux Kernel team but while still using GitHub, Bitbucket, or GitLab to do the peer review process.
Everything else I have tried including quilt and the various other tools that have attempted to do this all feel too complicated and too much work.
No offense to the authors of st-git and the work they have put in. But, personally the workflow with it has felt too complicated to me and not natural.
git-ps is the first way I have found where managing the stack of patches feels easy and natural while still allowing me to use GitHub, Bitbucket, or GitLab for peer review.
Check out my article on it here to understand the workflow better, https://upte.ch/blog/how-we-should-be-using-git/
I am happy to answer any questions I can.
git ps pull git ps rebase git ps ls git ps rr 0 git ps pub 0>git-ps is the first way I have found where managing the stack of patches feels easy and natural while still allowing me to use GitHub, Bitbucket, or GitLab for peer review.
Maybe it would be good to describe more what is happening behind the scenes when you do this "git ps" commands. At the end of article you mention that you need to know Git. I know it, but I don't know what is happening behind the scenes (I could probably test it myself by actually using git-ps, but I've just read this article)
This approach is interesting but sounds more complicated than patch series, and therefore more error prone.