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

461–470 of 548 posts

Re: GitHub Stacked PRs

#461

Post by philwelch »

pierrekin wrote: post #175
dminik wrote: post #168

Maybe this is just a skill issue, but even with several attempts I just can't figure out why I would use stacked diffs/PRs. Though maybe that's because of the way I work? I notice a lot of examples just vaguely mention "oh, you can have others review your previous changes while you continue working", but this one doesnt make sense to me. Often times, the first set of commits doesn't even make it to the end result. I'…

We use this feature extensively at $dayjob. Imagine you have some task you are working on, and you wish to share your progress with people in bite sized chunks that they can review one at a time, but you also don’t want to wait for their reviews before you continue working on your task. Using a stacked set of PRs you can continue producing new work, which depends on the work you’ve already completed, without waiting…

You can review PR’s commit by commit, and you can ask people to review PR’s commit by commit. Not a big deal.

Re: GitHub Stacked PRs

#462

Post by qsera »

saagarjha wrote: post #425
windward wrote: post #420

Earlier quoted context omitted.

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.

And they would be right, https://news.ycombinator.com/item?id=47766632

Re: GitHub Stacked PRs

#463

Post by mike_hearn »

tcoff91 wrote: post #83
Hamuko wrote: post #58

Earlier quoted context omitted.

> It amounts to doing N code reviews at once rather than a few small reviews which can be done individually I truly do not comprehend this view. How is reviewing N commits different from/having to do less reviews reviewing N separate pull requests? It's the same constant.

Let's compare 2 approaches to delivering commits A, B, C. Single PR with commits A, B, C: You must merge all commits or no commits. If you don't approve of all the commits, then none of the commits are approved. 3 stacked PRs: I approve PR A and B, and request changes on PR C. The developer of this stack is on vacation. We can incrementally deliver value by merging PRs A and B since those particular changes are block…

> You must merge all commits or no commits

This seems to be the root of the problem. Nothing stops a reviewer merging some commits of a PR, except a desire to avoid the git CLI tooling (or your IDE's support, or....). The central model used in a lot of companies requires the reviewee to do the final merge, but this has never been how git was meant to be used and it doesn't have to be used that way. The reviewer can also do merges. Merge (of whichever commits) = approval, in that model.

Re: GitHub Stacked PRs

#464

Post by [deleted] »

nathas wrote: post #436

Meanwhile, you still can't do fast-forward merges in GitHub :clown: https://github.com/orgs/community/discussions/4618 And it doesn't even rebase and merge correctly with fast-forward if there it's a clean set of commits! https://github.com/orgs/community/discussions/5524

[deleted]

Re: GitHub Stacked PRs

#465

Post by qsera »

jorams wrote: post #348
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?

So far you've only gotten responses to "how can a worse product win?", and they are valid, but honestly the problem here is that Mercurial is not a better product in at least one very important way: branches. You can visit any resource about git and branches will have a prominent role. Git is very good at branches. Mercurial fans will counter by explaining one of the several different branching options it has availab…

To me mercurials branching is closer to the development process and preserves more information, because it records the original branch a commit was made.

Git does not have such concept. That is a trade off and that trade off works great for projects managed like Linux kernel. But for smaller projects where there is a limited number of people working, the information preserved by mercurial could be very valuable.

It also had some really interesting ideas like change set evolution, which enabled history re-writing after a branch has been published. Don't know its current status and how well it turned out to be..

Re: GitHub Stacked PRs

#466

Post by charles_f »

nathas wrote: post #436

Meanwhile, you still can't do fast-forward merges in GitHub :clown: https://github.com/orgs/community/discussions/4618 And it doesn't even rebase and merge correctly with fast-forward if there it's a clean set of commits! https://github.com/orgs/community/discussions/5524

[flagged]

Re: GitHub Stacked PRs

#467

Post by qsera »

ptx wrote: post #432
Izkata wrote: post #412

Earlier quoted context omitted.

A little over a decade ago, with only svn experience, I tried both mercurial and git. There was something about how mercurial handled branches that I found extremely confusing (don't remember what), while git clicked immediately - even without reading the manual. So at least for me, git was clearly better.

Mercurial later added bookmarks which work like Git branches. These make more sense to me as well.

Did bookmarks moved as you made commits, like a branch pointer in git does?

Re: GitHub Stacked PRs

#468

Post by windward »

qsera wrote: post #460
windward wrote: post #420

Earlier quoted context omitted.

Mercurial can't rebase without an extension, or force push. Are you using a definition of strictly superior that means it has fewer features?

Mercurial's model is different from Git that these things you list does not make sense there. Rebase does not make sense in Mercurial because it has the concept of fixed branches. A commit is permanently linked to the branch on which it was made. So you are supposed to use merges. Same with force-pushing.

I know. It's an opinion about how to develop that a lot of people hold - a declining proportion, mind you, like Mecurial's declining market share - and it's one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior?

Believe me, I tried to have an open mind about it. Then one day I was getting ready to go on a work trip with a half-finished feature on my work laptop, and realised there was simply no in-model way for backing that wip up to the repo. If I lost my laptop, I lost the progress. mercurial-scm fails at SCM.

Re: GitHub Stacked PRs

#469

Post by mike_hearn »

eru wrote: post #283
jmalicki wrote: post #265

Earlier quoted context omitted.

Every time I've rewritten something from Python into Java, Scala, or Rust it has gotten around ~30x faster. Plus, now I can multithread too for even more speedups. Python is absurdly slow - every method call is a string dict lookup (slots are way underused), everything is all dicts all the time, the bytecode doesn't specialize at all to observed types, it is a uniquely horrible slow language. I love it, but python is…

> [...], it is a uniquely horrible slow language. To be fair, Python as implement today is horribly slow. You could leave the language the same but apply all the tricks and heroic efforts they used to make JavaScript fast. The language would be the same, but the implementations would be faster. Of course, in practice the available implementations are very much part of the language and its ecosystems; especially for a…

Python has a JIT compiling version in GraalPy. If you have pure Python it works well. The problem is, a lot of Python code is just callouts to C++ ML libs these days and the Python/C interop boundary just assumes you're using CPython and requires other runtimes to emulate it.

Re: GitHub Stacked PRs

#470

Post by tcoff91 »

mike_hearn wrote: post #463
tcoff91 wrote: post #83

Earlier quoted context omitted.

Let's compare 2 approaches to delivering commits A, B, C. Single PR with commits A, B, C: You must merge all commits or no commits. If you don't approve of all the commits, then none of the commits are approved. 3 stacked PRs: I approve PR A and B, and request changes on PR C. The developer of this stack is on vacation. We can incrementally deliver value by merging PRs A and B since those particular changes are block…

> You must merge all commits or no commits This seems to be the root of the problem. Nothing stops a reviewer merging some commits of a PR, except a desire to avoid the git CLI tooling (or your IDE's support, or....). The central model used in a lot of companies requires the reviewee to do the final merge, but this has never been how git was meant to be used and it doesn't have to be used that way. The reviewer can a…

Yes, the root of the problem is the workflow of the company being centered around GitHub instead of Git itself.

This feature helps improve GitHub so it's useful for companies that do this this way.

At our company, only admin users can actually directly git push to main/master. Everything else HAS to be merged via github and pass through the merge queue.

So this stacked PRs feature will be very helpful for us.

Post reply on HN