Hi, I would like to add one benefit to the list that I think is very important. A change-id header would allow standalone code review tooling and Git forges (e.g. GitHub, GitLab, Forgejo) to reliably track different versions of a patch. This would enable much improved code review experiences, not unlike what Gerrit users are enjoying already. Mailing list oriented projects like Git itself and the Linux kernel actually do code review more similar to the Gerrit model. There is a focus on the individual commits -- what will eventually end up on the master branch. A "force-push" to a PR/MR on a Git forge is conceptually similar to sending a new patchset to a mailing list. However, some people don't like that, because it makes it hard for reviewers to track what they have and haven't reviewed already. Their answer to this problem is to sequentially add meaningless "fixup commits" on top of a branch, making incremental code review easier. Often the branch is later squashed, to clean up the history a little bit. But that also loses important information in the process. Mailing lists don't suffer from this as much, because mail clients don't go out of their way to hide old patchset versions from users. However, they also don't provide any tools to help code reviewers associate old and new versions of patchsets. A change-id header could be essential in developing tooling for mailing lists that track patchsets and even individual patches within them across versions. Easily being able to view the interdiff between the last-reviewed version of a patchset and its most recent version is tremendously useful for any code review workflow. So I think that almost all members of the broader Git ecosystem would benefit in many ways from Git supporting this header directly. Remo
