Skip to content

Comment on How can we get GitHub to support fast-forward-only merges for PRs?parent

Comments

spirOP

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

spirOP

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?

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.