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

131–140 of 548 posts

Re: GitHub Stacked PRs

#131

Post by steveklabnik »

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 rest of the stack is dependent.

> If they’re not, why do you want to review them independently?

For this example, you may want review from both a backend engineer and a frontend engineer. That said, see this too though:

> that seems like something you can already do by just breaking a PR into commits and letting people look at one of those at a time.

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. Notifications go to all parties instead of the parties who care about each section. Both reviews can proceed independently in a stack, whereas they happen concurrently in a PR.

> If you approve change A and reject change B, then the feature is only half done.

It depends on what you mean by "the feature." Seen as one huge feature, then yes, it's true that it's not finished until both land. But seen as two separate but related features, it's fine to land the independent change before the dependent one: one feature is finished, but the other is not.

Re: GitHub Stacked PRs

#132

Post by guelo »

awesome_dude wrote: post #114
forrestthewoods wrote: post #104

Earlier quoted context omitted.

Mercurial has a strictly superior API. The issue is solely that OG Mercurial was written in Python. Git is super mid. It’s a shame that Git and GitHub are so dominant that VCS tooling has stagnated. It could be so so so much better!

Whatever your opinion on one tool or another might be - it does seem weird that the "market" has been captured by what you are saying is a lesser product. IOW, what do you know that nobody else does?

Network effects and marketing can easily prevent better tools from winning.

Re: GitHub Stacked PRs

#133

Post by tcoff91 »

steveklabnik wrote: post #120
tcoff91 wrote: post #88

Earlier quoted context omitted.

It's crazy that you're getting downvoted for this take. This isn't reddit people. You're not supposed to downvote just because you disagree. Downvotes are for people who are being assholes, spamming, etc... If you disagree with a take, reply with a rebuttal. Don't just click downvote.

Historically, hn etiquette is that it's fine to downvote for disagreement. This came from pg himself. That said, while he hasn't posted here for a long time, this is still in the guidelines: > Please don't post comments saying that HN is turning into Reddit. It's a semi-noob illusion, as old as the hills. https://news.ycombinator.com/newsguidelines.html

Well, I stand corrected.

Re: GitHub Stacked PRs

#134

Post by zzyzxd »

One mistake I see across many organizations is that sometimes they overthink how much order should matter.

Sure, your application has a dependency on that database, but it doesn't necessarily mean you can't deploy the application before having a database. If possible, make it acceptable for your application to stay in a crashloop until your database is online.

Re: GitHub Stacked PRs

#135

Post by charcircuit »

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…

>If you reject change A and approve change B, nothing can merge

The feature is also half done in this case. The author can fix up the concerns the reviewer had in A and then both can be merged at the same time.

Re: GitHub Stacked PRs

#136

Post by ghthor »

robertwt7 wrote: post #67

There’s a startup callled Graphite dedicated to stacked PRs. I have been using them for a while now I always wonder why github doesn’t implement something similar to this. I probaly will try and switch to GitHub to see if it works flawlessly

Yep, very happy with graphite at work.

Re: GitHub Stacked PRs

#137

Post by montag »

calebio wrote: post #106
adamwk wrote: post #25

As someone who used phabricator and mercurial, using GitHub and git again feels like going back to the stone ages. Hopefully this and jujutsu can recreate stacked-diff flow of phabricator. It’s not just nice for monorepos. It makes both reviewing and working on long-running feature projects so much nicer. It encourages smaller PRs or diffs so that reviews are quick and easy to do in between builds (whereas long pull…

I miss the Phabricator review UI so much.

Me too. And I'm speaking from using it at Rdio 15 years ago.

Nothing since (Gerrit, Reviewboard, Github, Critique) has measured up...

Re: GitHub Stacked PRs

#138

Post by mikeocool »

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

Re: GitHub Stacked PRs

#139

Post by js2 »

sunshowers wrote: post #109
js2 wrote: post #86

Earlier quoted context omitted.

> stacked diff workflow pioneered by Phabricator Ahem, pioneered by gerrit. But actually, I'm almost certain even that wasn't original art. I think gerrit just brought it to git. https://www.gerritcodereview.com/about.html

To my knowledge, stacked diffs were first done in the Linux kernel as stacks of patches sent over email. From there they spread to Google and Facebook. (Source: I worked on Facebook's source control team from 2012-2018 and did a lot of work to enable stacked diffs there.)

Right, I was thinking from a web-based UI. The "pull request" term is from git (AFAIK), but git itself was built to accommodate the earlier concept of mailing patches around. (Source: I've been using version control since RCS/SCCS days and contributed here and there to git in its infancy. Also an early user/contributor to Gerrit.)

Re: GitHub Stacked PRs

#140

Post by adamwk »

flyingcircus3 wrote: post #117
adamwk wrote: post #47

Earlier quoted context omitted.

Maybe there’s a git trick I don’t know, but I’ve found making small branches off each other painful. I run into trouble when I update an earlier branch and all the dependent branches get out of sync with it. When those earlier branches get rebased into master it becomes a pain to update my in-progress branches as well

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
Post reply on HN