251–260 of 308 posts
Sure merging with one single button is nice but I rarely do that, if I'm stacking PRs it's because I probably want to merge gradually.
Earlier quoted context omitted.
This is my confusion, we already have commits to bundle changes, why not simply allow commits to be reviewed independently within a pr?
Ok, then how do you approve/take the first 2 commits and not the last one? Or how do you insert a commit in between 2 commits or address feedback on a given commit? The person making the change is now going to have to run multiple confusing interactive rebases and git shenanigans, the rewrite the history of the PR branch on every feedback, then you have to re-review all the commits again because they are all differen…
Can someone explain to me what is the difference between whatever they added new and creating several PRs and "stacking" them by pointing one branch to another via the Github UI? I've always done that. Is it just a nice UI on top of that? Sure merging with one single button is nice but I rarely do that, if I'm stacking PRs it's because I probably want to merge gradually.
Earlier quoted context omitted.
It isn't arbitrary. A branch is the unit of change. You can stack branches on top of each other and merge them one at a time. You can also keep adding to the end of the stack as needed.
I understand that GitHub kinda ate the world on this, but using a branch PR as the basic unit of change seems like an arbitrary choice to me. Torvalds invented Git for work on the Linux kernel, and the basic unit of change there is commits over email. It's not uncommon for them to take some commits but reject others. Which isn't meant to say "pull requests are obviously wrong and commits over email are obviously corr…
After reading this article[0], it's become clear to me that what you want is a reference branch, which people propose changes to. Then there's the integration process that takes a unit of change (commit or PR) and then tests that the reference branch is after applying that change. If it's not, then that unit of changes is sent for rework. If it is, it's now become part of the reference branch and the next units of change needs to be able to work together with it.
In corporate work, I tend for the PR to be the unit of work, which means squashing and merging. But any PR is compared to the default branch, not each other. Anything that is not yet part of the default branch, even if approved, is unreliable. So as the author, you'll need to refresh your PR to not rely on an old state of the reference branch.
I think there is too much focus on the PR itself instead of the reference branch which reflect the true state of the next release. Like their PR was good at the time of writing, so it should be merged. Instead of whether merging their PR would break the reference branch.
[0] http://kroah.com/log/blog/2019/08/14/patch-workflow-with-mut...
Can someone explain to me what is the difference between whatever they added new and creating several PRs and "stacking" them by pointing one branch to another via the Github UI? I've always done that. Is it just a nice UI on top of that? Sure merging with one single button is nice but I rarely do that, if I'm stacking PRs it's because I probably want to merge gradually.
Earlier quoted context omitted.
I tried to look through this earlier. Am I right this is only available through the CLI? If so it’s a no go for me and my team. Which is too bad because it looks quite useful. An addition ability I would love, which is a MUCH bigger feature and I recognize that, would be multi-repo stacks. My company doesn’t use a monorepo, and I like that. But as we’ve been breaking monoliths sometimes a logical feature touches mult…
I was using my usual stacked PR approach without the CLI and it detected the stack. So I think the CLI just does the heavy lifting for you (although I prefer to stick to vanilla git rather than learning a new tool).
Hey from the GitHub Stacked PRs team! Excited to release this more broadly so anyone can start stacking: https://gh.io/stacks Would love to hear any feedback, especially with the UI and CLI. We've got a lot more updates to the PR experience in store! Also happy to answer questions about the design decisions we made. There's a bunch happening behind the scenes, and it's one of the largest launches in GitHub history co…
I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs? The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge…
I've been using the preview for a bit, and I'm quite surprised to see them expanding the preview with so many unfixed issue. For example, merging an entire stack is completely broken in many cases: https://github.com/github/gh-stack/discussions/212 You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably…
> For example, merging an entire stack is completely broken in many cases: https://github.com/github/gh-stack/discussions/212 > You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably the biggest gain of stacked PRs. I'm struggling to imagine what it offers at all if that doesn't work! Is it just a way…
Earlier quoted context omitted.
The seeming lack of engagement with prior art is so frustrating.
I think it's a very Microsoft thing. It's a parallel evolution of software branching from the microcomputer era.
I think it's telling how long it took GitHub to release a v1 of this feature. Folks have wanted this for a long time. Graphite came along and did it years ago (and I'm sure they pondered whether GitHub would do this). And the v1 is also a bit... basic, and buggy. And I'm surprised there's not clear documentation for agents (given using GitHub stacked PRs CLI won't be in models' training data yet). It does feel like G…