To summarize the comments in this thread so far...
* Signing your commits is a waste of time
* Signing your commits with SSH keys is bad because it conflates an ephemeral key with a permanent identity
* Signing your commits with anything but GPG isn't worth it
The first point is hard to argue against because the commenters who offered the opinion didn't give many details to understand their perspective.
The second, which is the most common sentiment so far, seems to be because people misunderstand that it doesn't have to be your push/pull key. It can be any SSH key, including a special-purpose key whose only job is to be held securely and act as a signing key.
And the third kind of suffers the same problem as the first -- not enough details are given to understand.
My problems with git commit signing mostly overlap with the critiques leveled against GPG. That said, git’s implementation of signed commits combined with Github/Gitlab’s validation framework of only respecting the current key on a user’s profile really makes commit signing’s usefulness limited.
The signatures are stored within the commit object and the only way to resign a commit is to rewrite history. Also you can only attach one signature to a commit, though this is less of an issue.
GPG has plenty of critiques that I do agree with: horrible defaults, difficulty of use, a key model that is outdated and does not serve the plethora of uses it’s now used for, etc.
All of this adds up, tbh, that ephemeral keys are probably no worse than a GPG key. If your GPG key is compromised (or lost), you won’t be resigning your entire git history with your new key. You will simply note somewhere visible that X key was valid until Y date and Z key is the current valid key. Any commits pushed after Y date with X key are suspect.
The point being, signed git commits regardless of what type of key you use really only validate that a particular person at a particular instant in time signed that commit.
If anything, using a more ephemeral and disposable key will encourage Github/Gitlab/etc. to start thinking about key rotation on user profiles. As it stands, if you change your GPG key in Github all commits made with your previous key become invalid until you change you GPG key back. The fact you can change your key back is probably also bad.
The current state of git commit signing is useful, but that usefulness rapidly decays as the commit ages.
I have a pretty decent security setup (password manager, multiple SSH identities, OTP 2FA, Yubikeys) but GPG is such a usability nightmare I don't want to touch it with a 10 foot pole.
That still doesn't answer why this needs to be solved by added SSH signing format to git (which everything in the ecosystem needs to adapt to) instead of creating a better gpg-keygen.
* Signing your commits is a waste of time
* Signing your commits with SSH keys is bad because it conflates an ephemeral key with a permanent identity
* Signing your commits with anything but GPG isn't worth it
The first point is hard to argue against because the commenters who offered the opinion didn't give many details to understand their perspective.
The second, which is the most common sentiment so far, seems to be because people misunderstand that it doesn't have to be your push/pull key. It can be any SSH key, including a special-purpose key whose only job is to be held securely and act as a signing key.
And the third kind of suffers the same problem as the first -- not enough details are given to understand.