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

151–160 of 548 posts

Re: GitHub Stacked PRs

#151

Post by OptionOfT »

mikeocool wrote: post #138
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…

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

I agree. PR merges for me are bisect points. That's when changes are introduced. Individual commits don't even always build.

And I don't rebase or squash because I need provenance in my job.

Re: GitHub Stacked PRs

#152

Post by jlebar »

sameenkarim wrote: post #94

[dead]

It's a matter of taste, but I much prefer the workflow in the tool I hacked together for this, https://github.com/jlebar/git-pr-chain.

In the tool I wrote, you have a single branch with linear history. PRs in the chain are demarcated via commit messages. You then don't need any special rebase / sync commands -- you can use regular `git rebase -i` to reorder commits or edit a commit in the middle of a stack. Literally the only special command I need is "push this branch to github as multiple PRs".

Anyway I hope that alongside the branch-based you've built tool in `gh` that there will be an API that I can target.

Re: GitHub Stacked PRs

#153

Post by d0mine »

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…

You are describing gerrit.

https://www.gerritcodereview.com/

Re: GitHub Stacked PRs

#154

Post by Phelinofist »

steveklabnik wrote: post #131
ninkendo wrote: post #107

> a chain of small, focused pull requests that build on each other — each one independently reviewable. I have never understood what this even means. Either changes are orthogonal (and can be merged independently), or they’re not. If they are, they can each be their own PR. If they’re not, why do you want to review them independently? If you reject change A and approve change B, nothing can merge, because B needs A t…

The canonical example here is a feature for a website that requires both backend and frontend work. The frontend depends on the backend, but the backend does not depend on the frontend. This means that the first commit is "independent" in the sense that it can land without the second, but the second is not, hence, a stack. The root of the stack can always be landed independently of what is on top of it, while the res…

If the layers of a stack have a disjoint set of reviewers things are viewed in separation which might lead to issues if there is no one reviewing the full picture.

Re: GitHub Stacked PRs

#156

Post by sameenkarim »

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.

The CLI is completely optional, you can create stacked PRs purely via the UI.

Also the rationale for having a chain of branches pointing to each other was so the diff in a PR shows just the relevant changes from the specific branch, not the entire set of changes going back to the parent/trunk.

Curious how you're thinking about it?

Re: GitHub Stacked PRs

#157

Post by flyingcircus3 »

adamwk wrote: post #140
flyingcircus3 wrote: post #117

Earlier quoted context omitted.

Stacking branches for any extended period of time is definitely a poor mixing of the concepts of branches and commits. If you have a set of changes you need to keep in order, but you also need to maintain multiple silos where you can cleanly allow the code to diverge, that divergence constitutes the failure of your efforts to keep the changes in order. Until you can make it effortless, maintaining a substantial commi…

This is what I understood as well, but it sounded like GP had success doing it; so I was curious if there was a trick I didn’t know about

I take from GP that they try to make their branches small, and keep the cycle of development->review->merging small, so that the problem stacked PRs seeks to solve doesn't materialize in the first place.

Stacked PRs in my experience has primarily been a request to merge in a particular order. If you're the only merger, as in GP's case, there's no need to request this of yourself.

Re: GitHub Stacked PRs

#158

Post by inetknght »

ameliaquining wrote: post #35
inetknght wrote: post #3

Cool. Now let me do it across multiple repos. I often end up with 10 or 20 PRs across a half dozen repos that need to be merged in specific order.

How would that work? Commits in different repos aren't ordered relative to one another. I suppose you could have a "don't let me merge this PR until after this other PR is merged" feature, but you could do that with a GitHub Action; it doesn't really need dedicated backend or UI support.

> How would that work?

In practical terms: I manually write a list of PRs, and maintain that list in the description of each of the PRs. Massive duplication. But it clearly shows the merge train.

Re: GitHub Stacked PRs

#159

Post by steveklabnik »

alkonaut wrote: post #144

Let's say I have the canonical example of a stack from main via a backend-pr and a frontend-pr. When my stack is done I send it for review to one frontend reviewer and one backend reviewer. Usually when you develop a "full stack" thing you continuously massage the backend into place while developing frontend stuff. If you have 10 commits for frontend and 10 for backend, they might start with 5 for backend, then 5 com…

> If you have 10 commits for frontend and 10 for backend

In this model, you tend to want to amend, rather than add more commits. And so:

> they might start with 5 for backend, then 5 commits to each branch to iron out the interface and communication,

You don't add more commits here, you modify the commits in your stack instead.

> Now I need to rebase my frontend branch to sit on B6?

Yes, when you change something lower in the stack, the things on top need to be rebased. Because your forge understands that they're stacked, it can do this for you. And if there's conflicts, let you know that you need to resolve them, of course.

But in general, because you are amending the commits in the stack rather than adding to it, you don't need to move anything around.

> And wouldn't this separation normally be obvious e.g. by paths?

In the simplest case, sure. But for more complex work, that might not be the case. Furthermore, you said you have five commits for each; within those sets of five, this separation won't exist.

Re: GitHub Stacked PRs

#160

Post by pastel8739 »

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.

Rebasing after merging a base branch becomes a pain though, when you do this. IMO the CLI will be nice to automate the process of rebasing each branch on its parent.
Post reply on HN