Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Better Model for Stacked Pull Requests

timothyandrew.dev

Post reply on HN
Print view View original

51–60 of 64 posts

Re: A Better Model for Stacked Pull Requests

#51

Post by mic47 »

capableweb wrote: post #50
mic47 wrote: post #49

First, never use --force, but use --force-with-lease -- this will fail to push in case someone make remote changes. Useful if you are collaborating on branches (or develop from more than 1 computers). > It can't pause when a conflict occurs, so you have to fix the conflict and (somehow) re-run it from the point it stopped at, which is fiddly at best. There is better way: 1. I use `git rebase -i` from the top of the s…

"force" is harmful not only because you might push over other people's changes, but because you're also introducing additional work for people who are using the branch you're force pushing to. No longer can those people simply run `git pull` to get a updated branch, since older references also changed. Solution is simply to never use force. Let the history be the history, don't overwrite it.

But for wast majority of pull request branches, people are not checking them out. And if so, they are not modifying it, so dropping local branch and checking fresh one is 20s additional work.

Additionally, technically speaking --force does not overwrite history, it just moves the branch pointer. Old commits are there.

Re: A Better Model for Stacked Pull Requests

#52

Post by tome »

mic47 wrote: post #51
capableweb wrote: post #50

Earlier quoted context omitted.

"force" is harmful not only because you might push over other people's changes, but because you're also introducing additional work for people who are using the branch you're force pushing to. No longer can those people simply run `git pull` to get a updated branch, since older references also changed. Solution is simply to never use force. Let the history be the history, don't overwrite it.

But for wast majority of pull request branches, people are not checking them out. And if so, they are not modifying it, so dropping local branch and checking fresh one is 20s additional work. Additionally, technically speaking --force does not overwrite history, it just moves the branch pointer. Old commits are there.

If they checkout `origin/branchname` rather than just `branchname` then `branchname` doesn't get created locally so they don't even have to drop the old one!

Re: A Better Model for Stacked Pull Requests

#53

Post by tome »

ilammy wrote: post #35
HALtheWise wrote: post #11

The article claims that GitHub doesn't support this workflow, but it actually does a pretty good job natively. In particular, if PR2 targets PR1, merging PR1 into master will automatically change the base branch of PR2 to be master, and PR2 will then be able to merge cleanly. I suspect this might not work as cleanly if you rebase or squash as the merge method, since you're destroying the historical information that g…

> I suspect this might not work as cleanly if you rebase or squash as the merge method It does not. After PR1 is merged, PR2 gets retargeted onto the target branch of PR1—but all the commits it was based on now move to the PR2, sometimes causing conflicts. GitHub won't automagically rebase your PR2, that makes sense.

I never understood why GitHub insists on creating a new commit for "Rebase and merge" when the branch is already ahead of master.

Re: A Better Model for Stacked Pull Requests

#54

Post by tome »

theptip wrote: post #41

I dislike the “merge from top to bottom of the stack” flow proposed as the “standard way”. I find that the bottom PRs get unwieldy; you can end up merging a multi-thousand line behemoth f1 containing f2, f3, etc. which is hard to verify as correct. Instead, merge f1 including any changes f1’ you may have force-pushed to that branch. Then do a ‘git rebase f2 —onto master’ where is the old f1 commit that you originally…

--onto seems to be the right way to me. I'm not sure why the article proposes a sequence of cherry-picks. That sounds more frustrating.

Re: A Better Model for Stacked Pull Requests

#55

Post by fwouts »

I really like seeing efforts being made in this direction. For the last few years I've been using git-town.com, which works quite well but I often end up having to work around it (especially when I have diamond-shaped branch dependencies, e.g. to refactor two independent things before implementing a small feature on top). I'll have to try this instead and compare!

Re: A Better Model for Stacked Pull Requests

#56

Post by cyphactor »

smcameron wrote: post #27
cyphactor wrote: post #17

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/

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

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

Re: A Better Model for Stacked Pull Requests

#57

Post by cyphactor »

bertr4nd wrote: post #22
ezyang wrote: post #12

While working on PyTorch, I also wrote an equivalent tool (funnily named nearly the same thing) for doing stack diffs ( https://github.com/ezyang/ghstack/ ), which most of our team uses for more complicated PRs. The UX for working on commits is a bit different than this tool though; instead of pushing branches individually, you just run "ghstack" on a stack of commits and it will create a PR per commit in the chain (…

ghstack is amazing. When I started working on PyTorch in GitHub I desperately missed the stacked diff workflow of Phabricator, and ghstack basically made me whole again :-).

In my opinion git-ps provides a much nicer patch workflow similar to Phabricator while still supporting GitHub, Bitbucket, or GitLab for peer reviews.

* https://github.com/uptech/git-ps * a detailed walkthrough https://upte.ch/blog/how-we-should-be-using-git/

Re: A Better Model for Stacked Pull Requests

#58

Post by ezyang »

tta wrote: post #37
ezyang wrote: post #12

While working on PyTorch, I also wrote an equivalent tool (funnily named nearly the same thing) for doing stack diffs ( https://github.com/ezyang/ghstack/ ), which most of our team uses for more complicated PRs. The UX for working on commits is a bit different than this tool though; instead of pushing branches individually, you just run "ghstack" on a stack of commits and it will create a PR per commit in the chain (…

This sounds pretty great, I wish I'd seen this a few months ago! One quick question: does this support adding commits to open PRs, or are you effectively locked in to one-commit-per-PR?

When you amend a commit and resubmit it to the PR, ghstack translates into pushing a new commit (not force pushing) to the PR. So yesish

Re: A Better Model for Stacked Pull Requests

#59

Post by ezyang »

cyphactor wrote: post #57
bertr4nd wrote: post #22

Earlier quoted context omitted.

ghstack is amazing. When I started working on PyTorch in GitHub I desperately missed the stacked diff workflow of Phabricator, and ghstack basically made me whole again :-).

In my opinion git-ps provides a much nicer patch workflow similar to Phabricator while still supporting GitHub, Bitbucket, or GitLab for peer reviews. * https://github.com/uptech/git-ps * a detailed walkthrough https://upte.ch/blog/how-we-should-be-using-git/

I definitely miss hg’s affordances like hg next/prev and restack. It doesn’t look like, though, that git-ps lets you submit multiple patches for review, this was the raison d’etre for ghstack

Re: A Better Model for Stacked Pull Requests

#60

Post by mpawelski »

cyphactor wrote: post #56
smcameron wrote: post #27

Earlier quoted context omitted.

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

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

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)

Post reply on HN