3 ms·
Uh, you're already beyond fucked if git.exe (or equivalent in *nix) is a hacked one and on your system. And similarly the same doomsday article does not exist f
by throwitaway222 3mo ago
Uh, you're already beyond fucked if git.exe (or equivalent in *nix) is a hacked one and on your system. And similarly the same doomsday article does not exist for VSCode, Zed, GitKraken, and a billion other tools that run git without caring to ask..
- UnwrapComment 3mo agoIn this case, simply cloning a repository containing such an executable is enough. This isn’t a common bug or a gotcha.
- ralferoo 3mo agoAlthough on Windows, the current directory is checked before PATH, unlike UNIX-based systems that require the current directory to be explicitly included in the PATH if that's the behaviour you want. So for any repository with git.exe in the root, if you then ran another git command from a DOS prompt with the repo as your current directory then it would give the same bad outcome of running the git.exe from the repo. I'm not saying that it's good that it's happening, but it doesn't seem like it's their bug to solve per se, it's just a feature of using Windows. Of course, they probably could work round it by parsing the PATH themselves and locating a git.exe that isn't in the current directory.