threads / discuss / 52714

packObjectsHook and the git executable

Subject: packObjectsHook and the git executable

## tl;dr

4 messages between Jan 30, 2020 and Jan 30, 2020.

replies: 3people: 2as markdown or json

Bryan Turner· Jan 30, 2020, 01:00 UTC · lore

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

Jeff King· Jan 30, 2020, 07:11 UTC · re: Bryan Turner · lore

Re: packObjectsHook and the git executable

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

Show 5 quoted lines

> 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.

Show 5 quoted lines

> 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

Bryan Turner· Jan 30, 2020, 07:38 UTC · re: Jeff King · lore

Re: packObjectsHook and the git executable

On Wed, Jan 29, 2020 at 11:11 PM Jeff King <peff@peff.net> wrote:

Show 12 quoted lines

>
> 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").

Show 13 quoted lines

>
> 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

Jeff King· Jan 30, 2020, 08:23 UTC · re: Bryan Turner · lore

Re: packObjectsHook and the git executable

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

Show 13 quoted lines

> 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