The following is my understanding.
Git identifies pretty much everything by sha1 hashes. Your signed tag references the commit by it's sha1 hash, the commit identifies the "tree" by it's sha1 hash and the "tree" references the files by their sha1 hashes.
So if you have two files with the same sha1 hash then you could replace one with the other and the signed tag would still validate just fine.
Practically I think the risk depends heavily on what you keep in your git repos. We don't have a preimage attack for SHA1 and we are unlikely to have any time soon. So we only have to worry about collision attacks.
If it is human readable source code reviewed by human reviewers then the risk is small. If someone can slip in a block of unexplained binary garbage and a conditional that does evil stuff based on the content of that block of binary garbage they can probably slip in malicious stuff without having to bother about sha1 collisions.
OTOH if it is being used to store binaries originated from untrusted sources there is more potential for trouble.