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

181–190 of 548 posts

Re: GitHub Stacked PRs

#181

Post by punkbit »

Smaug123 wrote: post #113
gregoryl wrote: post #97

Earlier quoted context omitted.

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

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

Re: GitHub Stacked PRs

#182

Post by quibono »

GitLab's UI around MRs (PRs) is IMO miles better than what GH's been offering. Try creating a PR from branch A to main, and then rebasing A. GitLab handles this fine and can show you changes between the two revisions; GitHub is completely lost.

Re: GitHub Stacked PRs

#183

Post by awesome_dude »

WolfeReader wrote: post #171
awesome_dude wrote: post #167

Earlier quoted context omitted.

I mean, in the fickle world that is TECH, I am struggling to believe that that's what's happened. I personally went from .latest.latest.latest.use.this (naming versions as latest) to tortoise SVN (which I struggled with) to Git (which I also was one of those "walk around with a few memorised commands" people that don't actually know how to use it) to reading the fine manual (well 2.5 chapters of it) to being an evang…

Mercurial has a more consistent CLI, a really good default GUI (TortoiseHg), and the ability to remember what branch a commit was made on. It's a much easier tool to teach to new developers.

Hmm, that feels a bit subjective - I'm not going to say X is easier than Y when I've just finished saying that I found both tools to have a lot of black magic happening.

But what I will point out, for better or worse, people are now looking at LLMs as Git masters, which is effectively making the LLM the UI which is going to have the effect of removing any assumed advantage of whichever is the "superior" UX

I do wish to make absolutely clear that I personally am not yet ready to completely delegate VCS work to LLMs - as I have pointed out I have what I like to think of as an advanced understanding of the tools, which affords me the luxury of not having an LLM shoot me in the foot, that is soley reserved as my own doing :)

Re: GitHub Stacked PRs

#185

Post by herpdyderp »

pastel8739 wrote: post #160
herpdyderp wrote: post #147

I thrive on stacked PRs but this sure seems like a weird way to implement support for it. Just have each branch point to their parent in the chain, the end. Just native Git. I've been longing for better GitHub support for this but the CLI is not where I need that support: just the UI.

Rebasing after merging a base branch becomes a pain though, when you do this. IMO the CLI will be nice to automate the process of rebasing each branch on its parent.

Agreed. I do have tooling for a rebase + push flow, but it simply calls native git commands.

Re: GitHub Stacked PRs

#186

Post by jwpapi »

This is probably driven to be more usable with AI agents, but smaller prs can create more code as they need to enforce more backwards compability, this can also lead to more code or more maintenance work.

Honestly I don’t see the benefit of smaller prs, except driving vanity scores?

Like I’m not saying you should

Re: GitHub Stacked PRs

#188

Post by aaronbrethorst »

forrestthewoods wrote: post #141
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?

Worse products win all the time. Inertia is almost impossible to overcome. VHS vs Betamax is a classic. iPod wasn’t the best mp3 player but being a better mp3 player wasn’t enough to claw market share. Google and Meta don’t use Git and GitHub. Sapling and Phabricator much much better (when supported by a massive internal team)

What was the better mp3 player than the iPod?

Re: GitHub Stacked PRs

#189

Post by TZubiri »

varun_ch wrote: post #115
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

in github's defense. This is a bit more nuanced, less objectively wrong domain posture issue. It will only matter if one security mechanism (subdomain control) fails.

The quoted microsoft examples are way worse. I see this with outbound email systems a lot, which is especially dangerous because email is a major surface of attack.

Re: GitHub Stacked PRs

#190

Post by explodes »

dastbe wrote: post #172
sameenkarim wrote: post #94

[dead]

How does this work with a tool like jujutsu that provides native support for stacking and preferably don't have a separate tool mucking about with state?

Using a platform-specific tool feels like vendor lock-in. Given the recent trends, behavior, and activity of GitHub, it sure seems like this is the opposite of what the world should be going for generally.

Also if someone could help me understand: Are these so-called stacked commits not possible with multiple commits on a single branch? I prefer to write my commits as atomic, independent, related changes, on a single branch, with both Git and Mercurial. I am apparently missing something: why can't a better UI simply show a multi-change PR?

Post reply on HN