[cyphactor]

I highly suggest reading my article on How we should be using Git. It covers a Git Patch Stack workflow, where it originated from and the tooling we built around it.

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.

https://upte.ch/blog/how-we-should-be-using-git/

[smcameron]

How does git-ps compare to stgit?

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

[cyphactor]

git-ps is an extension on top of Git to allow you to basically locally manage a stack of patches. Once you are then ready to have one of those patches peer reviewed you do a git ps rr <patch-index> and it takes and creates branch appropriately based on your patch stacks base and cherry-picks that patch into that branch, and then pushes that branch up.

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.

[mpawelski]

It's hard for me to tell what git-ps is actually doing behind the scene and how it works with GitHub, GitLab, Bitbuket and others. Looks like in some cases the commands are basically shortcuts to normal git commands (which is not bad thing in itself), and some command do more stuff but I don't know what.

    git ps pull

similar to: git pull --rebase origin master

    git ps rebase

similar to git rebase -i origin/master

    git ps ls 

similar to: git log --oneline origin/master..HEAD but display more info (Shows incremental commit numbers instead of hash. Shows this "rr" status, but when this "rr" status is shown? When we have remote branch for this commit/path?)

    git ps rr 0

This seems to do more. Like pushing the commit to some remote branch and some additional code to create pull request? What is actually the created branch name? (you need branchname to create PR in Github and others right?)

    git ps pub 0

This is merging branch created for "0" commit to master and push it to origin? How can it work with Github, Bitbucket where you often have protected master branch and must merge PR in web UI?

>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)

[marco_craveiro]

This. I was about to say,the kernel has solved this issue with patch series and tools like patchwork [1] and there is already a lot of experience on those workflows. What would be really nice is to have these kernel workflows in GitHub/GitLab (and, god forbid, stash/bitbucket), with UIs for mere mortals...

This approach is interesting but sounds more complicated than patch series, and therefore more error prone.

[1] https://patchwork.kernel.org/

[tboytim]

This guy! ^