[hoprocker]

This is generally a good flow, but something that absolutely baffles me is that GitHub changes the commit SHAs when branches are rebase-merged from PRs[0]. This totally breaks a fundamental notion in Git that the same work, based on the same commits, has the same hash. It also makes it incredibly difficult to determine which PR branches have been merged into master.

[0] https://docs.github.com/en/github/collaborating-with-issues-...

[leafmeal]

> This totally breaks a fundamental notion in Git that the same work, based on the same commits, has the same hash.

This is not a fundamental notion in git. The hash includes timestamps as well.

edit:

It also contains author and commiter details. Here's a slightly revised list borrowed from a blog post[1]

- commit message

- The file changes

- The commit author (and committer- they can be different)

- The date

- The parent commit hash(es)

[1]: https://www.mikestreety.co.uk/blog/the-git-commit-hash

[juped]

That is not something Github is doing, it's fundamental to how git works that different commits have different hashes - and rebasing creates different commits (they have different parents).

Not rebase-merging would probably suit your workflow better.

[comfydragon]

The page you linked to does subtly explain why that happens:

> Rebase and merge on GitHub will always update the committer information and create new commit SHAs

[lordgilman]

I really don't think this is a "fundamental notion in Git." They ship git-patch-id to do what you're trying to do and frequently used internal tools like git-cherry use it. It's also not a true statement for LKML-like workflows that are landing patches off of mailing lists with git-am or git-apply.