On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote: > I'm not sure how that'd work, since Git only allows a single PGP > signature per commit, as far as I can tell. When you rewrite the > history (by using rebase, say), the existing signatures of the rewritten > (rebased) commits are replaced with new ones generated from your key.
Is it so bad to re-sign commits on feature branches that we should lose the easy-to-read history of rebased branches? To me, it's much easier to understand and review a branch that has been updated by rebasing rather than merging. I think that counts for a lot. Do many people feel the same way? Re-signing the commits is messy but I don't think there's even been a consensus that it's very bad. I think that re-signing commits while rebasing is consistent with our security model which (as I understand it) considers committers' and their machines to be trusted. And that the meaning of the signature is merely that the committed changeset was definitively made by someone with the key.
