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

251–260 of 548 posts

Re: GitHub Stacked PRs

#251

Post by mckn1ght »

punkbit wrote: post #181
Smaug123 wrote: post #113

Earlier quoted context omitted.

No, it's a Git thing arising from squash commits. There are workflows to make it work (I've linked the cleanest one I know that works without force pushing), but ultimately they're basically all hacks. https://www.patrickstevens.co.uk/posts/2023-10-18-squash-sta...

This is actually a reasonable workflow. Although requires some preparation. I’ll try it out!

Yep that's how I do it if I have to deal with stacked PRs. I also just never use rebase once anything has happened in a PR review that incurs historical state, like reviews or other people checking out the branch (that I know of, anyways). I'll rebase while it's local to keep my branch histories tidy, but I'll merge from upstream once shared things are happening. There are a bunch of tools out there for merging/rebasing entire branch stacks, I use https://github.com/dashed/git-chain.

Re: GitHub Stacked PRs

#252

Post by 20k »

outworlder wrote: post #128
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!

> The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level…

Python is by far the slowest programming language, an order of magnitude slower than other languages

One of the reason mercurial lost the dvcs battle is because of its performance - even the mercurial folks admitted that was at least in part because of python

Re: GitHub Stacked PRs

#253

Post by forrestthewoods »

jstimpfle wrote: post #201
outworlder wrote: post #128

Earlier quoted context omitted.

> The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level…

[flagged]

[flagged]

Re: GitHub Stacked PRs

#254

Post by hokumguru »

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

Congrats and thank you. You helped build one of the best devex experiences I've ever had the pleasure of working with :)

Re: GitHub Stacked PRs

#255

Post by cush »

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…

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

Re: GitHub Stacked PRs

#256

Post by sam_bristow »

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.

What does Facebook use internally these days. I'm amazed that the state of review tools is still at or behind what we had a decade ago for the most part.

Re: GitHub Stacked PRs

#257

Post by meric_ »

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

Re: GitHub Stacked PRs

#258

Post by mhh__ »

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

Re: GitHub Stacked PRs

#259

Post by mhh__ »

1. Finally. Pull requests are consanguine and bizarre.

2. I'm not a huge fan of having to use a secondary tool that isn't formally a layer around git / like jj as opposed to github

Post reply on HN