I understand that if we sign a commit with the help of some arbitrarily strong hash, it doesn't protect the parent commit(s). The integrity of the SHA-1 hash references to the parent commits is not in question, but the authenticity of those commits themselves.

No, not the abstract tree formed by a series of commits.

The actual git ‘tree’ object, which is the thing a commit actually points to, referenced by a hash in the commit. That is signed by the GPG signature.

Correct. The content of the git `tree` is partially controlled by the attacker because filenames in the repository are part of it. So if it's feasible to manufacture a generic hash collision it MAY (not MUST) be feasible to generate two colliding `tree` objects.

The actual thing you'd attack with a hash collision is the blob object, not the tree object, right? The tree object has a rigid structure and git will throw a fit if you add non-functional data to modify its hash. Source code files have comments which make it much easier to manipulate the hash.

you're right, i worded that poorly. what i meant to imply was that a blob hash collision causes any tree referencing it to be malicious, which cascades down to many different commits/tags (potentially all of them, if the tree is untouched since repo creation).

Maybe you could make a valid tree object with the same hash and different content; the details about which graph node at which level is used as a target do not seem that important.