GitHub is nearly 15 years old, and there is still no way for a pull request merge to be fast-forward-only (linear history) AND preserve the same commits as pull request source branch.
Today, if you want to preserve commits in your development branch (and not squash them; squashing is great sometimes), you have two bad options:
1. merge commits. This is bad because linear history is an excellent risk reduction mechanism for a production build.
2. rebase commits. These would be ok, except when github rebases the commits into linear history, the commit hashes change (they are new commits) even though the patch and metadata are identical. So your development branch itself constantly needs to be rebased on your production branch, because the commits being added to production are newly created by github rebase & merge.
What we need is a fourth option "Fast-forward merge", which requires linear history and only preserves (ie copies) commits from the PR source branch into the target branch.
How can we get GitHub to care about this and action on it?
Then add a branch protection rule for the main branch with "Require linear history". This requires that PRs would otherwise fast forward.
Then disable everything but rebases. Rebases where the history doesn't need to be changed are fast-forwards. In fact, as far as I know, `--ff` isn't anything special other than "fail with an error if a rebase isn't just a fast-forward". There's no special functionality.
Pardon me, but I believe you misunderstand how GitHub has implemented "Rebase and Merge". In this case, github will generate new commit IDs even when the rebase is a no-op.
As far as I know, it's impossible to merge a GitHub pull request without one of squashing, generating a merge commit, or rewriting the commits. It is not possible to simply copy pre-existing commit IDs.
You can test this yourself. Simply checkout the main branch, add two new commits, push those commits to a dev branch, and try to merge them in a PR to main in a Rebase: you will observe that github has rewritten the commit IDs vs. the ones you generated locally on commit.
I feel like this is new and that I've never had this issue before with them... is this a regression? Or has this always been this way and I've never noticed? I'm a little surprised I didn't realize this...
np thanks for the response! It's always been this way. If you might know somebody at GitHub, maybe they could take a look at the linked feature request?
Today, if you want to preserve commits in your development branch (and not squash them; squashing is great sometimes), you have two bad options:
1. merge commits. This is bad because linear history is an excellent risk reduction mechanism for a production build.
2. rebase commits. These would be ok, except when github rebases the commits into linear history, the commit hashes change (they are new commits) even though the patch and metadata are identical. So your development branch itself constantly needs to be rebased on your production branch, because the commits being added to production are newly created by github rebase & merge.
What we need is a fourth option "Fast-forward merge", which requires linear history and only preserves (ie copies) commits from the PR source branch into the target branch.
How can we get GitHub to care about this and action on it?