# packObjectsHook and the git executable 4 messages from 2020-01-30 to 2020-01-30. Participants: Bryan Turner, Jeff King. Thread: https://gitlist.dev/t/52714 ## Bryan Turner, 2020-01-30 01:00 Subject: packObjectsHook and the git executable Message-ID: URL: https://gitlist.dev/e/CAGyf7-E%3D%3DgzsvP-ckK0kwHD%2Bf9pMmLBVpL4y2rC9tqk7ZiuW1g%40mail.gmail.com ``` 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, 2020-01-30 07:11 Subject: Re: packObjectsHook and the git executable Message-ID: <20200130071102.GA2189233@coredump.intra.peff.net> URL: https://gitlist.dev/e/20200130071102.GA2189233%40coredump.intra.peff.net In-Reply-To: ``` 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 ``` ## Bryan Turner, 2020-01-30 07:38 Subject: Re: packObjectsHook and the git executable Message-ID: URL: https://gitlist.dev/e/CAGyf7-HkUV43A79DKiDVvKnW5vuwsFz0KnZKj9bBQYc906VONg%40mail.gmail.com In-Reply-To: <20200130071102.GA2189233@coredump.intra.peff.net> ``` On Wed, Jan 29, 2020 at 11:11 PM Jeff King 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 ``` ## Jeff King, 2020-01-30 08:23 Subject: Re: packObjectsHook and the git executable Message-ID: <20200130082353.GA3442119@coredump.intra.peff.net> URL: https://gitlist.dev/e/20200130082353.GA3442119%40coredump.intra.peff.net In-Reply-To: ``` 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 ```