On 8/5/17, Junio C Hamano <gits...@pobox.com> wrote:
> Michael Forney <mfor...@mforney.org> writes:
>> On 8/5/17, Junio C Hamano <gits...@pobox.com> 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.