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

451–460 of 548 posts

Re: GitHub Stacked PRs

#451

Post by steveklabnik »

a_e_k wrote: post #377
steveklabnik wrote: post #164

Earlier quoted context omitted.

Stacked PRs tend to encourage a series of well-organized commits, because you review each commit separately, rather than together. What they do that the single branch cannot is things like "have a disjoint set of reviewers where some people only review some commits", and that property is exactly why it encourages more well-organized commits, because you are reviewing them individually, rather than as a massive whole.…

I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR. The curation of the commits that you'd do for stacked PRs could just as easily be done with commits on a single branch; some of us don't just toss random WIP and fixup commits on a branch and leave it to GitHub to squ…

> I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR.

That's what this feature is, conceptually. In practice, it does seem slightly more cumbersome due to the fact that they're building it on top of the existing, branch-based PR system, but if you want to keep it to one commit, you can (and that's how I've been working with PRs for a while now regardless, honestly).

They confirmed in other comments here that you don't have to use the CLI, just like you don't have to use gh in general to make pull requests, it's just that they think the experience is nicer with it. This is largely a forge-side UI change.

Re: GitHub Stacked PRs

#452

Post by seniorThrowaway »

kasey_junk wrote: post #404
awesome_dude wrote: post #114

Earlier quoted context omitted.

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?

GitHub had a business model where public repos were free. BitBucket didn’t. That’s it. That’s why git won, you could put up open source libs with one for free and not the other. Which is extra funny as the centralized service was the most important part of decentralized version control.

>the centralized service was the most important part of decentralized version control.

I've often thought this about github

Re: GitHub Stacked PRs

#453

Post by acjohnson55 »

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

They recently got bought by Cursor.

Re: GitHub Stacked PRs

#454

Post by withinboredom »

itsdesmond wrote: post #449
withinboredom wrote: post #365

Earlier quoted context omitted.

Sounds like what my teachers used to say: “a personal problem”. Literally nobody outside FB knows what they’re missing and until they fix that, literally nobody cares.

> Sounds like what my teachers used to say: “a personal problem”. They don’t sound like a very good teacher.

Judging by the amount of adults wandering around thinking their personal problems are everyone else’s problem… they were pretty good teachers.

Re: GitHub Stacked PRs

#455

Post by philwelch »

pierrekin wrote: post #178
WhyNotHugo wrote: post #124

I really don't get the point of stacked PRs. Just using git, you'd send a set of patches, which can be reviewed, tested and applied individually. The PR workflow makes a patch series an undivisible set of changes, which must be reviewed, tested and applied in unison. And stacked PRs tries to work around this issue, but the issue is how PRs are implemented in the first place. What you really want is the ability to rev…

The teams that I have worked with still apply the philosophy you’re describing, but they consider PRs to be the “commit”, i.e. the smallest thing that is sane to apoly individually. Then the commits in the PR are not held to the standard of being acceptable to apply, and they are squashed together when the PR is merged. This allows for a work flow in which up until the PR is merged the “history of developing the PR”…

Squashing is fine if you’re just making a mess of temporary commits as you work and you don’t want to keep any of those changes separate in master, but that’s not a useful review workflow. A lot of times I’ve built a feature in a way that decomposed naturally into e.g. two commits: one to do a preparatory refactor (which might have a lot of noisy and repetitive changes, like changing a function signature) and another to actually change the behavior. You want those changes to be separate because it makes the changes easier to review; the reviewer quickly skims the first commit, observes that it’s a mechanical refactor, and the change in behavior has its own, smaller commit without all the noise.

“What if there’s feedback and you need to make changes after the code review?” Then I do the same thing I did before I posted the code review: make separate “fixup” commits and do an interactive rebase to squash them into my commits. (And yes, I do validate that the intermediate commits build cleanly.)

There’s nothing you get from stacked PR’s that you don’t also get from saying “please review my feature branch commit by commit”.

Re: GitHub Stacked PRs

#456

Post by thamer »

Gigachad wrote: post #301
cush wrote: post #255

Earlier quoted context omitted.

It’s useful for large PRs in large repos with many contributors. It reduces the burden for reviewers.

Still not sure this is the right solution. My problem is if one of your first stages gets rejected in review or requires significant changes, it invalidates so much work that comes after it. I've always when possible preferred to get small stuff merged in to production as it happens rather than build an entire feature and put it up for review.

> it invalidates so much work that comes after it.

No, not necessarily.

I work on a large repo and new features often involve changes to 3 different services: 2 from the backend, and the frontend UI. Sending a single PR with changes to all 3 services is really not ideal: the total diff size in a feature I added recently was maybe 600+ lines, and the reviewers for frontend and backend changes are different people. The changes in the 2 backend services can be thought of as business logic on one side and interactions with external platforms on the other. The business logic can't work without integrating calls to external APIs, and the UI can't work without the business logic.

These days I open 3 separate PRs and the software only works once all 3 are merged and built. It would be great to have all of them as a single package that's still testable and reviewable as 3 distinct parts. The UI reviewer can check out the whole stacked PR and see it running locally with a functional backend, something that's not possible without a lot of manual work when we have 3 PRs.

Re: GitHub Stacked PRs

#457

Post by mike_hearn »

kqr wrote: post #307
landr0id wrote: post #266

Earlier quoted context omitted.

>At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. Fun story: I don't really know what Microsoft's server-side infra looked like when they migrated the OS repo to git (which, contrary to the name, contains more than just stuff related to the Windows OS), but after a few years the…

I have heard that the Google monorepo is called google3 but I don't know why. Maybe those things are common...

Probably a lot of Googlers don't know. It's ancient history, was called google3 even in 2006 when I first joined.

google1 = code written by Larry, Sergey and employee number 1 (Craig). A hacky pile of Python scripts, dumped fairly quickly.

google2 = the first properly engineered C++ codebase. Protobufs etc were in google2. But the build system was some jungle of custom Makefiles, or something like that. I never saw it directly.

google3 = the same code as google2 but with a new custom build system that used Python scripts to generate Makefiles. I suppose it required a new repository so they could port everything over in parallel with code being worked on in google2. P4 was apparently not that great at branches and google3 didn't use them. Later the same syntax for the build files was kept but turned into a new languages called Starlark and the Makefile generator went away in favor of Blaze, which directly interpreted them.

At least, that's the story I vaguely recall.

Re: GitHub Stacked PRs

#458

Post by philwelch »

KptMarchewa wrote: post #402
fphilipe wrote: post #323

Earlier quoted context omitted.

Sure, that's possible. I can also use the GitHub app and use a Git abstraction where I don't have to understand Git at all. The point is that I want to use Git, a tool and skill that is portable to other platforms.

That's like, most AI obsoleteable skill you could pick.

Not at all. One of the tricks of using AI is context management and managing the Git history yourself can be a big part of that. If the AI has a stupid idea and implements it, even when you tell it, “that was a stupid idea, don’t do that, change it back”, the history could persist and the stupid idea will poison the context window every time an agent reads the commit history. It’s even worse if you had the stupid idea!

Also, my current workflow actually has hooks to block agents from creating or changing commits. I know at some point this will be a limit to scaling, but I think that will result in me spending more rather than less time in git.

Re: GitHub Stacked PRs

#460

Post by qsera »

windward wrote: post #420
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!

Mercurial can't rebase without an extension, or force push. Are you using a definition of strictly superior that means it has fewer features?

Mercurial's model is different from Git that these things you list does not make sense there.

Rebase does not make sense in Mercurial because it has the concept of fixed branches. A commit is permanently linked to the branch on which it was made. So you are supposed to use merges.

Same with force-pushing.

Post reply on HN