Re: [PATCH] Drop some dashes from built-in invocations in scripts
- From
Michael Forney <mforney@mforney.org>
- Date
- Aug 6, 2017, 05:35 UTC
- Message-ID
- <CAGw6cBsYiGH1h8C8qFp-yX3arzkaRi_vghpjbErxjoYHXxpu+Q@mail.gmail.com>
- In-Reply-To
- <xmqqh8xlsiaq.fsf@gitster.mtv.corp.google.com>
On 8/5/17, Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
> Michael Forney <mforney@mforney.org> writes: >> On 8/5/17, Junio C Hamano <gitster@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.