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?
Comments
You seem to misunderstand a few Git things, as this feature has been available for a long time.
First, enable "Always suggest updating pull request branches". This improves DX.
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.
Huh, you're right. My apologies.
- https://github.com/Qix-/test-rebase/commits/master
- https://github.com/Qix-/test-rebase/pull/1/commits
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?