3 ms·
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
by spir 3y ago
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.
- junon 3y agoHuh, you're right. My apologies. - https://github.com/Qix-/test-rebase/commits/master https://github.com/Qix-/test-rebase/commits/master - https://github.com/Qix-/test-rebase/pull/1/commits 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...
- spir 3y agonp 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?