I used to be in boat where my first instinct was to disable SELinux but I must say it wasn't that hard.
You may consider writing a custom SELinux policy such that only the git executable can access the .git directory. This would be a much more useful mitigation against this attack, but it would also move the difficulty barrier significantly.
This was on a server so no popup - you also need to know where to look (/var/log/audit/audit.log) to actually work out what is causing the 'Bad Gateway' error in nginx.
At work, I have written an SELinux module for our java application servers. It properly reduces the permissions from system for the tomcat startup procedure, and then drops further permissions once the startup procedure actually executes a java binary. This two-step process is mostly necessary because the tomcat startup executes a bunch of shell scripts to setup variables, but I don't want to give the application server any execute-rights.
Conceptually, it's not hard to build such a module with some careful consideration about the files and permissions the process needs at different stages - I was surprised by this. But getting this module to work properly was a real hassle, because there's very little practical documentation on this.
Quite sad, actually. I want to be as smug as Redhat about SELinux stopping pentesters cold.