I was fascinated by the idea of `git send-email`, which I learned from
your efforts. Thank you for that. I have been trying to incorporate that
workflow for contributing little patches to open-source projects.
Creating a new fork (in GitHub) just to fix a typo is overkill. And
getting to send the patch without any client or third-party software or
service, just with an email address, is grand.

But I did find a problem with it. The patch when applied doesn't retain
the original commit hash. When editing the email with `--annotate`, it
does show the commit hash, but I can't find it in the sent email. The
problem with a mismatched hash for the same commit is that forked copy
of the code will give conflict when the contributor tries to pull from
upstream (after upstream has applied the patch, with a different commit
hash). I realize it's a small matter and easily fixed. But even so, it
could be avoided if `git send-email` and `git am` incorporated the
commit hash. Cause, why not? `git format-patch` already stores the hash.

-- 
Enan
3nan.ajmain@gmail.com
https://www.github.com/3N4N

GPG Key ID: 448F8D0D0D6DB601566E396CA031EA10A3ECB75D

On Wed Sep 21, 2022 at 4:50 PM CEST, Enan Ajmain wrote:
> But I did find a problem with it. The patch when applied doesn't retain
> the original commit hash. When editing the email with `--annotate`, it
> does show the commit hash, but I can't find it in the sent email. The
> problem with a mismatched hash for the same commit is that forked copy
> of the code will give conflict when the contributor tries to pull from
> upstream (after upstream has applied the patch, with a different commit
> hash). I realize it's a small matter and easily fixed. But even so, it
> could be avoided if `git send-email` and `git am` incorporated the
> commit hash. Cause, why not? `git format-patch` already stores the hash.

You should pull upstream with git pull --rebase, which should detect and
skip the applied patch. The hash must change because a new committer is
recorded.