"flaw in the processing of pathnames in Git on NTFS-based systems"
What ever happened to good old input validation ?
A new version of Git has been emitted to ward off attempts to exploit a potential arbitrary code execution vulnerability – which can be triggered by merely cloning a malicious repository. The security hole, CVE-2018-11235, reported by Etienne Stalmans, stems from a flaw in Git whereby sub-module names supplied by the . …
I've encountered developers who think it's a good idea to have production servers pull code directly from such repositories--and there are hordes of such repositories. I've had to deny access for such requests. Imagine the rate of spread if a repository were to be infected. I have my safeguards in place--but defense in depth needs to get deeper, much deeper.
You make a valid point, however it requires more context. I mean... you do realize that it's very easy to set up a construction using a specific refspec which makes sure that you don't pull it directly onto the master but another (sub)branch instead?
Or... what if the project makes sure that only production worthy code gets onto the master branch and everything else remains limited to the dev branches?
Ergo: you can pull code onto a production server, but that is no guarantee that it will also immediately go live right away.
Still; how is this any different from, say, a server pulling packages directly from a repository? It doesn't have to pose any risks, depending on context.
You make it sound as if this construction is always a bad idea, but it doesn't have to.