Description
Line 63 in d4e0bb9
It seems to me there's a potential defect here as there's more than one "name" for a git operation's executable. For example, if the entry point is git-fetch it will not strictly match git.
Also cases where the first found item is a symlink/hard-link to the second doesn't seem handled. (This case would actually require the true answer be the third on the path - or the second executable not equal to the current executable, don't even get me started on overlays lol)
An answer here is to get the entry executable, find its true location (realpath), test if it a git-* name, and compare if any of the path entries are hard or soft links. Sadly, it can still be that the other is a non-linked copy, and so on and so on...
I think the truth is that this handling of executable chains is more dangerous then is immediately obvious and there's things that can be at play that no defensive coding exists.
Perhaps another mitigation is to allow the direct specification of the "true git client" via an env var, a known path (such as /etc/git/git_shim_binary` that shows the correct value... Lots of options, but navigating the path this way seems very scary (TM)