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

111–120 of 548 posts

Re: GitHub Stacked PRs

#111

Post by raincole »

smallmancontrov wrote: post #70
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'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.

This matches my experience 100%. I was about to write a similar comment before I see yours.

Re: GitHub Stacked PRs

#112

Post by IshKebab »

ghighi7878 wrote: post #93
masklinn wrote: post #80

Earlier quoted context omitted.

Merge trains are an integration method. In GitHub that’s called merge queues. Stacked PRs are a development method, for managing changes which are separate but dependent on one another (stacked). The two are orthogonal they can be used together or independently (or not at all).

Ahh so stacked diffs? https://docs.gitlab.com/user/project/merge_requests/stacked_...

Yes, except with a proper UI. Also while you could do this on GitHub before in the same way that that Gitlab feature works, it didn't work cross-repo so in practice it wasn't an option for most open source code.

I can't remember if Gitlab has the same limitations but I do remember trying to use Gitlab's stacked diffs and finding them to not work very well. Can't remember why tbh.

Re: GitHub Stacked PRs

#113

Post by Smaug123 »

gregoryl wrote: post #97
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…

If I'm following correctly, the conflicts arise from other commits made to main already - you've implicitly caught branch A up to main, and now you need catch branch B up to main, for a clean merge. I don't see how there is any other way to achieve this cleanly, it's not a git thing, it's a logic thing right?

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

Re: GitHub Stacked PRs

#114

Post by awesome_dude »

forrestthewoods wrote: post #104
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.

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?

Re: GitHub Stacked PRs

#115

Post by varun_ch »

TZubiri wrote: post #46

github.github.com? Not the first time github does something highly weird with their domains (like publishing docs from a subdomain of their public github pages service) I think they have a culture of circumventing 'official' channels and whoever is in charge of a thing is whoever publishes the thing. I think it's a great way to train users to get phished by github impostors, if tomorrow we see an official download fr…

https://news.ycombinator.com/item?id=47614038

Re: GitHub Stacked PRs

#116

Post by worldsayshi »

forrestthewoods wrote: post #104
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.

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!

Maybe forgejo has a shot?

Re: GitHub Stacked PRs

#117

Post by flyingcircus3 »

adamwk wrote: post #47
cleverdash wrote: post #30

As a solo dev I rarely need stacked PRs, but the underlying problem, keeping PRs small and reviewable, is real even when you're your own reviewer. I've found that forcing myself to break work into small branches before I start (rather than retroactively splitting a giant branch) is the actual discipline. The tooling just makes it less painful when you don't. Curious whether this changes anything for the AI-assisted w…

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 commit structure and constantly rebasing to add changes to the proper commit quickly turns into more effort than just waiting to the end and manually editing a monster diff into multiple sensible commits. But we take the challenge and tell ourselves we can do better if we're proactive.

Re: GitHub Stacked PRs

#118

Post by steveklabnik »

smallmancontrov wrote: post #70
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'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.

What is kind of funny here is that you're right locally. 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. So while the git CLI was super fast, and the hg CLI was slow, "performance" means more than just CLI speed.

I was never a fan of hg either, but now I can use jj, and get some of those benefits without actually using it directly.

Re: GitHub Stacked PRs

#119

Post by jrochkind1 »

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?

Welcome to VHS and Betamax. the superior product does not always win the market.

Re: GitHub Stacked PRs

#120

Post by steveklabnik »

tcoff91 wrote: post #88
Arainach wrote: post #53

Earlier quoted context omitted.

Looking at multiple commits is not a good workflow: * It amounts to doing N code reviews at once rather than a few small reviews which can be done individually * Github doesn't have any good UI to move between commits or to look at multiple at once. I have to find them, open them in separate tabs, etc. * Github's overall UX for reviewing changes, quickly seeing a list of all comments, etc. is just awful. Gerrit is mi…

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

Post reply on HN