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

421–430 of 548 posts

Re: GitHub Stacked PRs

#421

Post by mattstir »

inerte wrote: post #73

Looks interesting, but it seems you need to know the final shape of the stack before you start creating Pull Requests. So it's useful if you create Pull Request A, then immediately start working on something that builds on top of A, create a Pull Request for that (while A is still a PR), then you can do A->B->C Here's something that would be useful: To break down an already big PR into multiples that make up a stack.…

It appears the CLI is only half-baked so far. Given how many things they've borrowed from Graphite (a tool which adds this type of workflow), it should only be a matter of time until they add a `split` command. Graphite lets you split a large set of changes by commit or by hunk which is very handy.

Re: GitHub Stacked PRs

#422

Post by mattstir »

j3g6t wrote: post #196

Super excited to give this a whirl - i've been messing with graphite's `gt` command for stacking and it's been relatively decent but I didn't love needing to bring in another tool/service/account when I only care about the stacking behaviour. Was a fun experiment but nice I can simplify back onto `gh` and `git`

I hope that GitHub continues copying Graphite's homework in terms of functionality, because from what I can see they don't have equivalents to `gt split`, absorb, and so on. Those can be very useful in the right contexts.

Re: GitHub Stacked PRs

#423

Post by avita1 »

AJRF wrote: post #366

I have never got a good answer to "can't you just make smaller PRs". This is convoluted tooling (needs its own CLI) for something you could achieve with just learning how git works.

IMO this tool is basically allowing you to do that, it just takes care of the bookkeeping to associate the series of smaller PRs with eachother which is possible today but requires a lot of clicking.

Re: GitHub Stacked PRs

#424

Post by ttoinou »

tcoff91 wrote: post #75
jenadine wrote: post #66

I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit: - merge some commits independently when partial work is ready. - mark some commit as reviewed. - UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is famil…

It's basically trying to bring the stacked diff workflow pioneered by Phabricator to GitHub. The idea is that it allows you to better handle working on top of stuff that's not merged yet, and makes it easier for reviewers to review pieces of a larger stack of work independently. It's really useful in larger corporate environments. I've used stacked PRs when doing things like upgrading react-native in a monorepo. It r…

Even with one developer on a repo this sounds like useful

Re: GitHub Stacked PRs

#425

Post by saagarjha »

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?

When I ask for this people like to explain that these are bad features nobody should want.

Re: GitHub Stacked PRs

#426

Post by mattstir »

zmmmmm wrote: post #290

Curious how / how well it deals with conflicts in the different branches that are part of the stack. Is there some support for managing that, or what happens when two of the branches don't rebase / merge cleanly?

> If a rebase conflict occurs, the operation pauses and prints the conflicted files with line numbers. Resolve the conflicts, stage with git add, and continue with --continue. To undo the entire rebase, use --abort to restore all branches to their pre-rebase state.

So it tries to replay commits in the stack and will stop halfway through that individual stack (layer?) to let you fix it if there's a conflict.

Re: GitHub Stacked PRs

#427

Post by saagarjha »

dbetteridge wrote: post #299
eru wrote: post #288

Earlier quoted context omitted.

The point of what? I hope they fixed phabricator in the meantime.

The point is the main branch reflects the "units" of change, not the individual commits to get there. One merged pr is a unit of change, at the end of the day the steps you took to produce it aren't relevant to others. My opinion of course, I'm open to understanding why preserving individual commits is beneficial

A unit of change is a commit. I have no idea why you'd think a PR is a unit of change.

Re: GitHub Stacked PRs

#428

Post by saagarjha »

MrJohz wrote: post #180
mikeocool wrote: post #138

Earlier quoted context omitted.

Constantly rewriting git history with squashes, rebases, manual changes, and force pushes has always seemed like leaving a loaded gun pointed at your foot to me. Especially since you get all of the same advantages with plain old stream on consciousness commits and merges using: git merge --no-ff git log --first-parent git bisect --first-parent

I find rebases are only a footgun because the standard git cli is so bad at representing them - things like --force being easier to write than --force-with-lease, there being no way to easily absorb quick fixes into existing commits, interdiffs not really being possible without guesswork, rebases halting the entire workflow if they don't succeed, etc. I've switched over pretty much entirely to Jujutsu (or JJ), which…

--force-with-lease is useless if you ever use tools that refresh git status.

Re: GitHub Stacked PRs

#429

Post by Izkata »

js2 wrote: post #139
sunshowers wrote: post #109

Earlier quoted context omitted.

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

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

Re: GitHub Stacked PRs

#430

Post by samsin »

'Large pull requests are hard to review' is a good reason to keep PRs small, but small PRs also encourage continuous integration/delivery/deployment. Stacked PRs sound like they encourage long-lived feature branches instead.
Post reply on HN