[ymse]

Oddly, the author recommends signing commits, yet uses only fast-forward merges. Little do they know that signed commits necessarily can not be resolved as fast-forwards in a merge situation, since that would require changing the signatures!

Rebasing is the answer, but that will of course re-sign every commit with your key. In a shared repository, I prefer creating "useless" merge commits to changing other peoples signatures.

[scottnonnenberg]

My local configuration doesn't need to be ready to create merge commits because those happen on GitHub/GitLab/etc. When I rebase, it's my own pull request on top of a more recent master - the signer remains me.

[rlpb]

Perhaps I misunderstand you, but a fast forward merge isn't really a merge (there is no merge commit) and by definition doesn't change any commits. So it doesn’t require changing any commits, and therefore no signatures need changing either.

Is there some other part of a workflow that you're inferring here that will need changing commits?

[growse]

If you have a feature branch with multiple commits signed by multiple people, does rebasing that not invalidate the signatures (changes the parent and thus every hash)?

[rlpb]

I see. The rebasing you mention is part the implied workflow I was missing. I see it now. Yes - if the rule is that merge commits to master are not permitted (ie. all commits must be rebased onto master first), then of course one person cannot rebase someone else's signed commits without losing those signatures. Thanks.

Theoretically one could devise a tool which allows each contributor to re-sign (in the correct order), but I'm not aware that any such thing exists, and it'd probably be too impractical anyway.