Handling signed git commits with revoked GPG key

Question

I have been signing git commits for a while with GPG key "A". After a while I decided to revoke that key and start using GPG key "B". I also continued signing new git commits with key "B".

I still keep both keys (the revoked key "A" and new key "B") locally. New commits are ok, but the problem I'm now having is that all the old git commits signed with revoked key "A" are displayed with red warning when viewed with git log --show-signature.

Here's how this warning looks in git log (most of it is screaming red):

commit 39a53e42c8856278f481b9035e54eb90d8d2a0b7
gpg: Signature made Sat Aug  1 22:24:38 2015 CEST using RSA key ID 2F7EF26C
gpg: Good signature from "My Name <email1>" [ultimate]
gpg:                 aka "My Name <email2>" [ultimate]
gpg: WARNING: This key has been revoked by its owner!
gpg:          This could mean that the signature is forged.
gpg: reason for revocation: Key is superseded
gpg: revocation comment: New GPG key is used.
gpg: revocation comment: New key fingerprint: C464 17C1 4F7B D54E A082  7090 CAFA 7B1B 2914 ED81
gpg: revocation comment: New key id:          2914ED81
Author: My name <email1>
Date:   Sat Aug 1 22:24:38 2015 +0200

    Improve test helper

Is there a setting I can tell git or gpg that this key is still "ok" and trust-able, it's just that I'm not using it anymore? (I wanna keep this old key revoked)

I'd appreciate if gpg (or git) "mildly" indicated the key is not in use instead of suggesting forged commits. Is there a security or trust setting I could set to achieve this?

Answer 1

Update Q4 2016 with Git 2.11:

git log introduces additional status codes E, X, Y, R for ERRSIG, EXPSIG, EXPKEYSIG, and REVKEYSIG, so that a user of %G? gets more information.
See Verifying signed git commits?

---

There doesn't seem much to do in your case.

That was debated in 2010, including an interesting idea as a best practice:

You can of course have more than one e-mail address per key, but you should NEVER have more than one key per e-mail.

This is pretty common actually.
At the very least it will happen if people are trying to transition between an older and a newer key --- for example, if they are trying to move from a less secure crypto algorithm to a more secure crypto algorithm.

As I understand things the best way to manage these kinds of things is to use sub-keys. You can change the expire time on a sub-key, and then eventually you can revoke it, all the while preserving your one primary public key for signing.
Indeed it's a good idea to regularly change your sub-key and expire the older ones.

See if you can use subkeys (following for instance this tutorial or this one):

OpenPGP further supports subkeys, which are like the normal keys, except they're bound to a master key pair. A subkey can be used for signing or for encryption.
The really useful part of subkeys is that they can be revoked independently of the master keys, and also stored separately from them.