Hacker News Reader

Comment by bnchrch | Hacker News Reader

Well this is a great addition! I've worked in places where `squash and merge` was standard procedure and others (including currently) where `rebase and merge` was the standard.

It's nice to see the later finally getting some love so I don't have to keep going back to my own terminal after my PR is approved.

View on HN

> others (including currently) where `rebase and merge` was the standard.

Isn't the usual standard "rebase && merge --no-ff?" Yielding a merge commit but lower branch interleaving in the logs? This is going to dump all the branch's commit into the mainline.

Some projects (like Chromium) squash all of the contributor's commits into a single commit representing their entire local branch history (it was local, no one needs to see their "aw shit I broke the tests" commit), and then rebases that commit and lands it directly on top of master.

Github already supported that with the second merge method they introduced ("squash").

Best part I think is that it's possible to make this the only allowed merge strategy for a repo.

I wonder if this preserves the link to the PR the commits were issued from - I'd hate to lose the ability to reference code review comments for a commit.

> so I don't have to keep going back to my own terminal after my PR is approved.

Why would you have to go back to your terminal after the PR is approved? In either case, the merges are done by the admin..

This would be true if we had one person responsible for the merge! We have a small team of developers and proper rebase and merge is the responsibility of the PR author after it has passed code review + testing.

In short: all devs are admins.

edit: anyway this would still be a huge help to the sole admin if we had one.

Because sometimes the admin just tells you "ok, rebase then I will merge" and don't bother doing the rebase himself...

If there is a conflict during the rebase, the developer working on the new feature will have more information on how to fix it. So it makes sense for the developer to rebase before submitting.

Why would you have a separate "admin" do that? It doesn't require a separate skillset; the developer is in the best position to shepherd their feature into production, and by giving them ownership of their feature they can stick closer to solving the actual problem, and likely get more satisfaction from their work as well.

Reply on news.ycombinator.com