This is generally a good flow, but something that absolutely baffles me is that ...

leafmeal · on Jan 25, 2021

> 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 · on Jan 26, 2021

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 · on Jan 25, 2021

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 · on Jan 25, 2021

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.