6 ms·

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` w

by bnchrch 10y ago

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.

ilkkao 10y ago
Best part I think is that it's possible to make this the only allowed merge strategy for a repo.
mkagenius 10y ago
> 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..
- bnchrch 10y ago
  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.
- ni-hil 10y ago
  Because sometimes the admin just tells you "ok, rebase then I will merge" and don't bother doing the rebase himself...
  - dsp1234 10y ago
    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.
- lmm 10y ago
  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.
masklinn 10y ago
> 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.
- phasmantistes 10y ago
  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.
  - masklinn 10y ago
    Github already supported that with the second merge method they introduced ("squash").
threecheese 10y ago
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.

by bnchrch 10y ago

ilkkao 10y ago

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

mkagenius 10y ago

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

bnchrch 10y ago
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.
ni-hil 10y ago
Because sometimes the admin just tells you "ok, rebase then I will merge" and don't bother doing the rebase himself...
- dsp1234 10y ago
  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.
lmm 10y ago
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.

masklinn 10y ago

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

phasmantistes 10y ago
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.
- masklinn 10y ago
  Github already supported that with the second merge method they introduced ("squash").

threecheese 10y ago

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.