packObjectsHook and the git executable

packObjectsHook and the git executable

[Bryan Turner]

In upload-pack.c, when Git invokes the packObjectsHook, it's
hard-coded to pass "git". Unless it modifies the PATH environment
variable, though, if the script were to invoke the provided command
line as-is, it may end up running a different version of Git than the
version being used to run upload-pack (or http-backend).

Is there any way the packObjectsHook could be passed the "right" git
executable? Or am I missing some surrounding context that means
executing "git" is somehow guaranteed to invoke the "right" binary?
(Perhaps this same PATH-related caveat applies to other places where
Git invokes itself recursively?)

Grateful for any insight!
Bryan

Re: packObjectsHook and the git executable

[Jeff King]

On Wed, Jan 29, 2020 at 05:00:18PM -0800, Bryan Turner wrote:

> In upload-pack.c, when Git invokes the packObjectsHook, it's
> hard-coded to pass "git". Unless it modifies the PATH environment
> variable, though, if the script were to invoke the provided command
> line as-is, it may end up running a different version of Git than the
> version being used to run upload-pack (or http-backend).

We do modify PATH to put git's exec-path at the start. This happens in
setup_path(), which is called by the main "git" executable (so "git
upload-pack" before it hits cmd_upload_pack()).

Programs which are invoked directly as "git-upload-pack" need to call
that function on their own (which happens when upload-pack is invoked
over ssh). But upload-pack and http-backend do that.

> Is there any way the packObjectsHook could be passed the "right" git
> executable? Or am I missing some surrounding context that means
> executing "git" is somehow guaranteed to invoke the "right" binary?
> (Perhaps this same PATH-related caveat applies to other places where
> Git invokes itself recursively?)

I think all is working as designed, but if you have a reproducible case
where we run the "wrong" git, I can take a look at it.

-Peff

Re: packObjectsHook and the git executable

[Bryan Turner]

On Wed, Jan 29, 2020 at 11:11 PM Jeff King <peff@peff.net> wrote:
>
> On Wed, Jan 29, 2020 at 05:00:18PM -0800, Bryan Turner wrote:
>
> > In upload-pack.c, when Git invokes the packObjectsHook, it's
> > hard-coded to pass "git". Unless it modifies the PATH environment
> > variable, though, if the script were to invoke the provided command
> > line as-is, it may end up running a different version of Git than the
> > version being used to run upload-pack (or http-backend).
>
> We do modify PATH to put git's exec-path at the start. This happens in
> setup_path(), which is called by the main "git" executable (so "git
> upload-pack" before it hits cmd_upload_pack()).

Thanks, that's a missing piece I'd overlooked (and explains why
everything is written the way it is, to use "git").

>
> Programs which are invoked directly as "git-upload-pack" need to call
> that function on their own (which happens when upload-pack is invoked
> over ssh). But upload-pack and http-backend do that.
>
> > Is there any way the packObjectsHook could be passed the "right" git
> > executable? Or am I missing some surrounding context that means
> > executing "git" is somehow guaranteed to invoke the "right" binary?
> > (Perhaps this same PATH-related caveat applies to other places where
> > Git invokes itself recursively?)
>
> I think all is working as designed, but if you have a reproducible case
> where we run the "wrong" git, I can take a look at it.

I suspect it's a case of a broken Git build. Not that Git is doing
anything wrong, or has any problems with its build, to be clear--I
mean instead that someone ran a local build and didn't set it up
"right". Correct me if I'm wrong but:
- If the GIT_EXEC_PATH environment variable isn't set, Git will use
the path that was compiled in when it was built
- If that Git is installed in a different path (i.e. compiled for
/usr/local but installed in /opt), the compiled-in exec path may not
exist or not contain "git"
- In that case, "git" gets run from wherever it's found in $PATH and
you get whatever version that happens to be

Does something like that seem like it could happen?

Thanks as always for your insights!
Bryan

>
> -Peff

Re: packObjectsHook and the git executable

[Jeff King]

On Wed, Jan 29, 2020 at 11:38:23PM -0800, Bryan Turner wrote:

> I suspect it's a case of a broken Git build. Not that Git is doing
> anything wrong, or has any problems with its build, to be clear--I
> mean instead that someone ran a local build and didn't set it up
> "right". Correct me if I'm wrong but:
> - If the GIT_EXEC_PATH environment variable isn't set, Git will use
> the path that was compiled in when it was built
> - If that Git is installed in a different path (i.e. compiled for
> /usr/local but installed in /opt), the compiled-in exec path may not
> exist or not contain "git"
> - In that case, "git" gets run from wherever it's found in $PATH and
> you get whatever version that happens to be
> 
> Does something like that seem like it could happen?

Yes, that's quite plausible. One easy way to trigger that is to run Git
out of the build directory without a "make install". That's why we have
the bin-wrappers/ subdirectory, which sets up the exec-path to use the
built-but-not-installed version (and that's what we use when running the
test suite).

-Peff