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

GitHub Stacked PRs

github.github.com

Post reply on HN
Print view View original

91–100 of 548 posts

Re: GitHub Stacked PRs

#91

Post by tcoff91 »

inerte wrote: post #73

Looks interesting, but it seems you need to know the final shape of the stack before you start creating Pull Requests. So it's useful if you create Pull Request A, then immediately start working on something that builds on top of A, create a Pull Request for that (while A is still a PR), then you can do A->B->C Here's something that would be useful: To break down an already big PR into multiples that make up a stack.…

It looks like in the UI if you base a PR on another branch you can just check a box to make it a stack. So I don't think you have to know the full shape of the stack in advance unless you're using the cli.

I use jj to stack branches so i'll just be using the UI to do github pr stacks.

Re: GitHub Stacked PRs

#92

Post by xixixao »

akersten wrote: post #79

Does it fix the current UX issue with Squash & Merge? Right now I manually do "stacked PRs" like this: main If PR B merges first, PR A can merge to main no problems. If PR A merges to main first, fixing PR B is a nightmare. The GitHub UI automatically changes the "target" branch of the PR to main, but instantly conflicts spawn from nowhere. Try to rebase it and you're going to be manually looking at every non-conflic…

Conflicts spawn most likely because PR A was squashed, and once you squash Git doesn't know that PR B's ancestors commits are the same thing as the squashed commit on main.

No idea if this feature fixes this.

Edit: Hopefully `gh stack sync` does the rebasing correctly (rebase --onto with the PR A's last commit as base)

Re: GitHub Stacked PRs

#93

Post by ghighi7878 »

masklinn wrote: post #80
ghighi7878 wrote: post #72

What's difference between stacked PRs and merge trains in gitlab?

Merge trains are an integration method. In GitHub that’s called merge queues. Stacked PRs are a development method, for managing changes which are separate but dependent on one another (stacked). The two are orthogonal they can be used together or independently (or not at all).

Ahh so stacked diffs? https://docs.gitlab.com/user/project/merge_requests/stacked_...

Re: GitHub Stacked PRs

#95

Post by nine_k »

tcoff91 wrote: post #38
kardianos wrote: post #32

Earlier quoted context omitted.

I continue to use gerrit explicitly because I cannot stand github reviews. Yes, in theory, make changes small. But if I'm doing larger work (like updating a vendored dep, that I still review), reviewing files is... not great... in github.

Most editors have some kind of way to review github PRs in your editor. VSCode has a great one. I use octo.nvim since I use neovim.

Can these tools e.g. do per-commit review? I mean, it's not the UI what's the problem (though it's not ideal), it's the whole idea of commenting the entire PR at once, partly ignoring the fact that the code in it changes with more commits pushed.

Phabricator and even Gerrit are significantly nicer.

Re: GitHub Stacked PRs

#96

Post by varun_ch »

whalesalad wrote: post #12

At first I thought this was a user submitted project due to the subdomain of github.com but then realize the subdomain is also github. Is this an official channel for this sort of thing? Surprised this isn't on the official blog.

it's a GitHub Pages site in the @GitHub org from a repo called gh-stack (i.e. the repo is at https://github.com/github/gh-stack/).

There’s a special case where certain official orgs can continue to use github.com instead of github.io for their Pages domain, and that’s how you end up with:

https://github.github.com/gh-stack/

from the code:

Should Pages owned by this user be regarded as “Official GitHub properties”?

def github_owned_pages? GitHub.github_owned_pages.include?(login) end

# Orgs/users that are owned by GitHub and should be allowed to use # `github.com` URLs. # # Returns an Array of String User/Organization logins. ...

Re: GitHub Stacked PRs

#97

Post by gregoryl »

akersten wrote: post #79

Does it fix the current UX issue with Squash & Merge? Right now I manually do "stacked PRs" like this: main If PR B merges first, PR A can merge to main no problems. If PR A merges to main first, fixing PR B is a nightmare. The GitHub UI automatically changes the "target" branch of the PR to main, but instantly conflicts spawn from nowhere. Try to rebase it and you're going to be manually looking at every non-conflic…

If I'm following correctly, the conflicts arise from other commits made to main already - you've implicitly caught branch A up to main, and now you need catch branch B up to main, for a clean merge.

I don't see how there is any other way to achieve this cleanly, it's not a git thing, it's a logic thing right?

Re: GitHub Stacked PRs

#98

Post by atq2119 »

People have been building stacked PR workflows on top of GitHub for a while now. It's great to see that the message seems to have finally landed at GitHub, but what is actually new here in GitHub itself (i.e., not counting the gh CLI tool)?

There seems to be a native stack navigation widget on the PR page, which is certainly a welcome addition.

The most important question though is whether they finally fixed or are going to fix the issues that prevent submitting stacked PRs from forks. I don't see any indication about that on the linked page.

Re: GitHub Stacked PRs

#100

Post by eptcyka »

tcoff91 wrote: post #75
jenadine wrote: post #66

I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit: - merge some commits independently when partial work is ready. - mark some commit as reviewed. - UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is famil…

It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub. The idea is that it allows you to better handle working on top of stuff that's not merged yet, and makes it easier for reviewers to review pieces of a larger stack of work independently. It's really useful in larger corporate environments. I've used stacked PRs when doing things like upgrading react-native in a monorepo. It r…

What if main/master moves in between reviews?
Post reply on HN