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

211–220 of 548 posts

Re: GitHub Stacked PRs

#211

Post by sameenkarim »

ezekg wrote: post #9
bsimpson wrote: post #5

Finally! I never understood the PR=branch model GitHub defaulted to. Stacked commits (ala Phabricator/Gerrit) always jived more with how my brain reasons about changes. Glad to see this option. I guess I'll have to install their CLI thing now.

My only complaint off the bat is the reliance on the GH CLI, which I don't use either. But maybe by the time it's GA they'll have added UI support.

Stacked PRs can be created via the UI, API, or CLI.

You can also run a combination of these. For ex, use another tool like jj to develop locally, push up the branches, and use the gh CLI to batch create a stack of n PRs, without touching local state.

Re: GitHub Stacked PRs

#212

Post by forrestthewoods »

jstimpfle wrote: post #203
forrestthewoods wrote: post #143

Earlier quoted context omitted.

They died because everyone knows that Python is infact very very slow. And that’s just totally fine for a vast number of glue operations. It’s amusing you call Git fast. It’s notoriously problematic for large repos such that virtually every BigTech company has made a custom rewrite at some point or another!

Now that is interesting too, because git is very fast for all I have ever done. It may not scale to Google monorepo size, it would ve the wrong tool for that. But if you are talking Linux kernel source scale, it asolutely, is fast enough even for that. For everything I've ever done, git was practically instant (except network IO of course). It's one of the fastest and most reliable tools I know. If it isn't fast for…

The fact that Git has an extremely strong preference for storing full and complete history on every machine is a major annoyance! “Except for network IO” is not a valid excuse imho. Cloning the Linux kernel should take only a few seconds. It does not. This is slow and bad.

The mere fact that Git is unable to handle large binary files makes it an unusable tool for literally every project I have ever worked on in my entire career.

Re: GitHub Stacked PRs

#213

Post by sheept »

OJFord wrote: post #149
mikeocool wrote: post #138

Earlier quoted context omitted.

Constantly rewriting git history with squashes, rebases, manual changes, and force pushes has always seemed like leaving a loaded gun pointed at your foot to me. Especially since you get all of the same advantages with plain old stream on consciousness commits and merges using: git merge --no-ff git log --first-parent git bisect --first-parent

Until someone merges master into their feature branch rather than rebasing it. (And then that branch later gets merged.)

This shouldn't be a problem if you stick to commits and merges. --first-parent will skip past commits, including merge commits, in merged branches.

Re: GitHub Stacked PRs

#214

Post by ninkendo »

steveklabnik wrote: post #209
ninkendo wrote: post #204

Earlier quoted context omitted.

> If you do this in a PR, both get assigned to review the whole thing. Each person sees the code that they don't care about, because they're grouped together. There are two separate issues you’re bringing up: - Both groups being “assigned” the PR: fixable with code owners files. It’s more elegant than assigning diffs to people: groups of people have ownership over segments of the codebase and are responsible for appr…

> fixable with code owners files. Code owners automatically assigns reviewers. You still end up in the state where many groups are assigned to the same PR, rather than having independent reviews. > I already said GitHub lets you view single commits during PR review. Yes, you can look at them, but your review is still in the context of the full PR. > And I didn’t even bring up the fact that you can just open a second…

> You still end up in the state where many groups are assigned to the same PR

> Yes, you can look at them, but your review is still in the context of the full PR.

Why is this a bad thing? I don’t get it. This has literally never been a problem once in my career. Is the issue that people can’t possibly scroll past another discussion? Or… I seriously am racking my brain trying to imagine why it’s a bad thing to have more than one stakeholder in a discussion.

I can think of a lot of reasons why doing the opposite, and siloing off discussions, leads to disaster. That is something I’ve encountered constantly in my career. We start out running an idea past group A, they iterate, then once we reach a consensus we bring the conclusion to group B and they have concerns. But oh, group A already agreed to this so you need to get on board. So group B feels railroaded. Then more meetings are called and we finally bring all the stakeholders together to discuss, and suddenly hey, group A and B both only had a partial view of the big picture, and why didn’t we all discuss this together in the first place? That’s happened more times in my career than I can count. The number of times group B is mad that they have to move their finger to scroll past what group A is talking about? Exactly zero.

Re: GitHub Stacked PRs

#215

Post by NooneAtAll3 »

ameliaquining wrote: post #22
ezekg wrote: post #9

Earlier quoted context omitted.

My only complaint off the bat is the reliance on the GH CLI, which I don't use either. But maybe by the time it's GA they'll have added UI support.

You can in fact do this from the web UI: https://github.github.com/gh-stack/guides/ui/#creating-a-sta...

damn, I missed it as well

presenting only cli commands in announcement wasn't a good choice

Re: GitHub Stacked PRs

#216

Post by contravariant »

bsimpson wrote: post #5

Finally! I never understood the PR=branch model GitHub defaulted to. Stacked commits (ala Phabricator/Gerrit) always jived more with how my brain reasons about changes. Glad to see this option. I guess I'll have to install their CLI thing now.

Huh interesting, my mental model is unable to see any difference between them.

I mean a branch is just jamming a flag into a commit with a polite note to move the flag along if you're working on it. You make a long trail, leave several flags and merge the whole thing back.

Of course leaving multiple waypoints only makes sense if merging the earlier parts makes any sense, and if the way you continue actually depends on the previous work.

If you can split it into several small changes made to a central branch it's a lot easier to merge things. Otherwise you risk making a new feature codependent on another even if there was no need to.

Re: GitHub Stacked PRs

#217

Post by sameenkarim »

SamuelAdams wrote: post #207
ezekg wrote: post #9

Earlier quoted context omitted.

My only complaint off the bat is the reliance on the GH CLI, which I don't use either. But maybe by the time it's GA they'll have added UI support.

CLI is great because now I can tell my AI agent to do it. “Fix all dependabot security issues (copy logs) and run tests to validate functionality. Create each dependency as its own stack (or commit) so that contributors may review each library update easily.” Wait 10 minutes and you’re done.

We're shipping a skill file with the CLI: https://skills.sh/github/gh-stack/gh-stack

Everyone will have their own way of structuring stacks, but I've found it great for the agent to plan a stack structure that mirrors the work to be done.

Re: GitHub Stacked PRs

#218

Post by contravariant »

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…

Oh that's annoying, seems to me there wouldn't have been an issue if you just merged B into A after merging A into main, or the other way around but that already works fine as you pointed out.

I mean if you've got a feature set to merge into dev, and it suddenly merges into main after someone merged dev into main then that's very annoying.

Re: GitHub Stacked PRs

#219

Post by godzillafarts »

herpdyderp wrote: post #147

I thrive on stacked PRs but this sure seems like a weird way to implement support for it. Just have each branch point to their parent in the chain, the end. Just native Git. I've been longing for better GitHub support for this but the CLI is not where I need that support: just the UI.

+1 this isn’t something new, it’s been possible all along in native git if you’re willing to do branch management and rebasing yourself. Just without the fancy UI / stack map.

Re: GitHub Stacked PRs

#220

Post by sameenkarim »

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…

Yes, we handle this both in the CLI and server using git rebase --onto

  git rebase --onto
So for ex in this scenario:

  PR1: main
When PR 1 and 2 are squash merged, main now looks like:

  S1 (squash of A+B), S2 (squash of C+D)
Then we run the following:

  git rebase --onto S2 D branch3
Which rewrites branch3 to:

  S1, S2, E, F
This operation moves the unique commits from the unmerged branch and replays them on top of the newly squashed commits on the base branch, avoiding any merge conflicts.
Post reply on HN