On 8/5/17, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Michael Forney <mforney@xxxxxxxxxxx> writes: >> On 8/5/17, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Have you made sure that all of these scripts, before calling >>> 'git-foo' in the current code, update their PATH so that these found >>> in the bog standard place (i.e. GIT_EXEC_PATH)? >>> >>> The reason I ask is because we can rest assured these changes will >>> be a no-regression improvement if you did so. I do not offhand >>> think of a reason why these scripts wouldn't be doing so, but it >>> never hurts to make sure. >> >> I just checked and all the scripts make some other call to a built-in >> with `git foo`, so I think it should be safe. > > As long as they are the same "foo"'s, then the check you did is > perfectly fine. The (unlikely I would think) case that can lead to > a regression is if these script deliberately used `git-foo` to find > them on $PATH, which can be different from 'git foo' that is found > by 'git' in its own binary (as all of them are built-ins), and that > is why I asked. Ah. Well, it looks like all but git-merge-resolve.sh run `. git-sh-setup`, so we know that GIT_EXEC_PATH must in their PATH (and at the front unless the script was invoked directly). git-merge-resolve.sh does not do this, so I suppose if the user ran $GIT_EXEC_PATH/git-merge-resolve directly, and also had a custom git-merge-index executable in their PATH, that would switch to running the git merge-index built-in instead.