Removing "Rebase and Merge" from GitHub

Anyone mind if we turn off “Rebase and Merge” as a valid merge strategy for PRs in GitHub? I still find “Squash and Merge” nice sometimes, but “Rebase” breaks the “every commit in the branch history ought to build, at least in theory” maxim.

cc @tkremenek, @Ben_Cohen

3 Likes

I’m not sure I follow how it breaks that maxim. The rebase occurs prior to commit and just moves your new commit to the top of the tree before committing. It helps with keeping a linear history which only helps make it easier to ensure that the tree stays buildabkr at any cut.

If your PR has three commits A-B-C in it, it may be the case that HEAD builds and A builds but not A rebased on HEAD, even if A-B-C rebased on HEAD does.

A linear history buys us nothing these days. Bisecting based on first-parent history is sufficient to get the same effect given the way we’re using PRs and cross-branch merges.

2 Likes

Makes sense. We should have one merge strategy, either merge commits or a linear history through rebasing. Having both options just makes it easy for someone to do the “wrong”* thing.

*wrong here just means they are being inconsistent with the rest of the git history.

Given that the tested rev isn’t the commit that winds up landing – it can be and often is many hours or even days of racing against the movement of master underfoot – I don’t think this change will buy you the maxim you’re after. But it will exclude one failure mode (“feature branch has non-buildable intermediate commits”) and concur we might as well do that.

1 Like

I would support removing rebase and merge.

Okay, I turned it off. Thanks, everyone!