I think you're confused here (or maybe I am). In this scenario you e.g. would be replacing the blob object for kernel/pid.c. Whereas the GPG signature facility

I think you're confused here (or maybe I am). In this scenario you e.g. would be replacing the blob object for kernel/pid.c. Whereas the GPG signature facility in git is creating a "tag" object with a signature of the preceding part of the object envelope, and that envelope refers to another object type. E.g. in the case of signed tags usually a commit object. So if you are able to replace the blob the GPG signature will still be valid, since it relies on signing the SHA-1 DAG. There is e.g. the third-party git-evtag[1] which gets around this problem by recursively unpacking the signed content, which does give you the advantages of the stronger hash. But this isn't how signed content in Git itself currently works. I think there was some recent-ish discussion of having something like that in git itself, and perhaps I've missed something, but I'm pretty sure I didn't miss the tag signing code doing a full object walk, which is what you'd need for signing a SHA-1 Git repository in a way that didn't piggy-back on SHA-1's security.