Right, so someone could create a malicious /tmp/.git. You then go to /tmp/experiment to do something and run some git commands.
Easy fix: on boot, have the "rc" script create a root-owned /tmp/.git dummy file with r-------- permissions.
Someone can also create a /tmp/foo/.git; but to be susceptible to that, you have to be under /tmp/foo.
That's another user's directory. What are you doing in there? Serves you right.
If /tmp/foo is your own, and someone planted a .git into it, that's your problem too: you're creating material in /tmp that is accessible to others, which is a security no-no.
Probably, this should be fixed in the kernel: the kernel should not allow a regular user to create a hidden directory (i.e. name starting with ".") in /tmp. Or probably any hidden object.
Such a fix is more general: it fixes the issue for any git-like program that walks up the tree looking for a special dot directory or file, including all such programs not yet written.
The rule could be general, such that creating a hidden object in a directory is only allowed to the directory's owner, not just to anyone who has write permissions to the directory.
In other words, if multiple users have write access to a directory, such as /tmp, but any other kind
of directory, then they are not allowed to perpetrate hidden objects on each other (both because
those things don't show up under "ls" without "-a" and because programs find those and react to them).
In fact, I would go one step further and enforce the kernel rule that writing to an existing dot file is denied to
anyone other than the owner that file, regardless of its write permissions.