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

471–480 of 548 posts

Re: GitHub Stacked PRs

#471

Post by gpm »

conor_f wrote: post #395
gpm wrote: post #313

Earlier quoted context omitted.

When I've reached for stacked PRs (in the past, not using this feature) it's precisely because I've split my change into smaller PRs being merged individually. I've just written those smaller PRs at once, or in quick enough succession that the previous PRs weren't merged before the later ones were ready. And the later ones relied on the previous ones because that's how working on a feature works. The earlier PRs are…

This is a perfect example that I've often seen in practice. There's nothing blocking in this workflow at all, and no reason these changes cannot be made in independent changes. e.g. 1) API implementation - Including tests and docs this should be perfectly acceptable to merge and review independently 2) UX implementation - Feature flagged, dummy API responses, easy to merge + review 3) One quick "glue" PR where the fe…

You're creating more work for no reason. There is absolutely no reason to make dummy API responses, a feature flag (well unless you want to delay public release of the features - domain dependent here), or a glue PR.

Moreover you haven't even eliminated the dependency. The UI PR requires knowing that the dummy API responses you've created fit the right format - i.e. approval of the API PR up to small nits.

Just test against the actual implementation from the start. Even without stacked PRs just leave the second as a draft with both sets of commits until the first is merged then rebase and make it.

Stacked PRs are superior here because they eliminate that extra work of the draft PR and parallelize the review process slightly better.

Re: GitHub Stacked PRs

#472

Post by ak217 »

littlecranky67 wrote: post #408
smallmancontrov wrote: post #70

Earlier quoted context omitted.

I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git*†‡" and every time I tried it wound up being dog slow (always) or broken (some of the time). Git is fugly but it's fast, reliable, and fugly, and I can work with that.

I might be the outlier, but am I the only one who doesn't care much about the speed of git? I've been using git since 2011 as my main vcs for personal and professional work as a freelancer contractor. Whenever I "wait" for git, it is either limited by the bandwidth (git clone) or by the amount of commit hooks that I implemented for linting, verification etc. The percentage of time actually spent in git internal execu…

I spent a long time educating teams of developers about git's usability quirks. I don't do that as much anymore - partly because the quirks have been worked out, partly because the developers have better guardrails and resources to learn from.

This whole time (the past 15 years) git has been getting faster without most of us noticing, because big companies have been investing in speeding it up. The reason you don't notice or care is that they work on a very different scale. Thousands of users, thousands of PRs per day, millions of CI/CD jobs all hitting the repo.

Now the cycle is repeating again because these numbers are shooting through the roof because of agentic coding.

Re: GitHub Stacked PRs

#473

Post by js2 »

Izkata wrote: post #429
js2 wrote: post #139

Earlier quoted context omitted.

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.)

> The "pull request" term is from git (AFAIK) Possibly from github. It got popularized there at least, encouraging forking code, and is why so many people say "pull request" when they mean "merge request".

GitHub took the "pull request" terminology from Git. A kernel developer (say) would have a bunch of changes ready in their local Git server and would request a pull from Linus, hence a pull request. There's literally a command for it:

https://git-scm.com/docs/git-request-pull

The command is so old it's still written in shell:

https://github.com/git/git/blob/master/git-request-pull.sh

It was first added July 27, 2005:

https://github.com/git/git/commit/ab421d2c7886341c246544bc8d...

https://lore.kernel.org/git/20050726073036.GJ6098@mythryan2....

But even then, it simply codified existing terminology.

Ah, someone else did the research, so minimally BitKeeper had the "pull" command first and the term "pull request" falls naturally from that:

https://rdnlsmith.com/posts/2023/004/pull-request-origins/

Re: GitHub Stacked PRs

#474

Post by jd3 »

sameenkarim wrote: post #220
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 newl…

We dealt with this headache for 7+ years at my former employer. Thanks so much for this.

Re: GitHub Stacked PRs

#475

Post by meric_ »

mhh__ wrote: post #258
meric_ wrote: post #257

I loved using sapling / mercurial so much at work that I ended up using the sapling SCM vsc extension at home all the time for personal work. Only downside is that Phabricator is not open source so viewing it in most things sucks. Hoping now I can get a much better experience

Phabricator is open source and has been for years. It has had a bumpy ride over the last few years though. Although I guess having written that I assume the internal meta one is much better

Huh, that's news to me. I had to do some googling and the only one I could find was by Phalicity which seems to be from a Meta employee who left and made it into a company (a la Statsig, or to some extent Graphite)

Seems that company shutdown though a while ago and it got forked into Phorge, but either way I assume there's some divergence from what's internal at this point.

Still I'll look into it, it does look neat and might suit my preferences still. Thanks for the headsup :)

Re: GitHub Stacked PRs

#476

Post by Ericson2314 »

Gabrys1 wrote: post #355
alwillis wrote: post #344

Earlier quoted context omitted.

> I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git". It wasn't the Mercurial team saying it was faster than Git; that was Facebook after contributing a bunch of patches after testing Mercurial on their very large mono-repo in 2014 [1]: For our repository, enabling Watchman integration has made Mercurial’s status command more than 5x faster than Git’s…

You can push to GitHub using Sapling. I wish Sapling open source was given more love, as the experience for non-Facebookers is subpar. No bash completion outside the box, no distro packages, no good help pages, random issues interacting with a Git repo...

Sapling and JJ can sort it out, the outside world will only care for one of them.

Re: GitHub Stacked PRs

#477

Post by ptx »

qsera wrote: post #467
ptx wrote: post #432

Earlier quoted context omitted.

Mercurial later added bookmarks which work like Git branches. These make more sense to me as well.

Did bookmarks moved as you made commits, like a branch pointer in git does?

Yup: https://mercurial-scm.org/help/commands/bookmarks

Re: GitHub Stacked PRs

#478

Post by WhyNotHugo »

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”…

Doesn’t this mean that a first review might request that a specific change be reverted, and then a later reviewer reviews that reversion? That’s essentially reviewing a noop, but understanding the it’s a noop requires carefully checking all previous now-invalidated changes.

Re: GitHub Stacked PRs

#479

Post by ezekg »

bmitc wrote: post #208
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.

Why don't you use the CLI?

Because git is all I need.

Re: GitHub Stacked PRs

#480

Post by surajrmal »

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.

Why not use gerrit? It's pretty similar.
Post reply on HN