Is it a good idea to GPG sign old git commits?

I just realized that I forgot to tell git to use my GPG key. I had made a number of commits without signing them. Should I go back and sign them?

I am not referring to whether or not I should sign tags, but I decided to sign commits themselves. I don't believe I can think of any reason not to, other than having a corrupted git history that may or may not be what I wrote. I trust GitHub to not mess around with my git history and I am the only author of about 99% of my projects, so given that, should I do so?

I found this answer, so I know now it is possible, but philosophically speaking, should I?

If the commits have already been published, you should not rewrite them for any purpose (except removing accidental data leaks), as this would change their commit IDs. (Remember that each commit's ID is based on SHA-1 hashes of its content and its parent commit.)

That means it'd require rewriting (and resigning) all subsequent commits, and would cause troubles for anyone who had already fetched any of those commits.

But for the same reason, you don't need to sign those old commits explicitly, at least not for data integrity purposes. Since each commit contains SHA-1-based IDs of its parents, verifying any single commit will also implicitly verify its entire history via the hash chain. It doesn't matter that the chain is a little longer or shorter.

On the other hand, if you don't trust SHA-1 for security, then you should consider commit signing entirely useless, since commits' file contents are also referred to by SHA-1 hashes. The only thing you sign directly (and not a hash thereof) is the commit message.