* packObjectsHook and the git executable @ 2020-01-30 1:00 Bryan Turner 2020-01-30 7:11 ` Jeff King 0 siblings, 1 reply; 4+ messages in thread From: Bryan Turner @ 2020-01-30 1:00 UTC (permalink / raw) To: Git Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: packObjectsHook and the git executable 2020-01-30 1:00 packObjectsHook and the git executable Bryan Turner @ 2020-01-30 7:11 ` Jeff King 2020-01-30 7:38 ` Bryan Turner 0 siblings, 1 reply; 4+ messages in thread From: Jeff King @ 2020-01-30 7:11 UTC (permalink / raw) To: Bryan Turner; +Cc: Git Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: packObjectsHook and the git executable 2020-01-30 7:11 ` Jeff King @ 2020-01-30 7:38 ` Bryan Turner 2020-01-30 8:23 ` Jeff King 0 siblings, 1 reply; 4+ messages in thread From: Bryan Turner @ 2020-01-30 7:38 UTC (permalink / raw) To: Jeff King; +Cc: Git Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: packObjectsHook and the git executable 2020-01-30 7:38 ` Bryan Turner @ 2020-01-30 8:23 ` Jeff King 0 siblings, 0 replies; 4+ messages in thread From: Jeff King @ 2020-01-30 8:23 UTC (permalink / raw) To: Bryan Turner; +Cc: Git Users 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-30 8:23 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-30 1:00 packObjectsHook and the git executable Bryan Turner 2020-01-30 7:11 ` Jeff King 2020-01-30 7:38 ` Bryan Turner 2020-01-30 8:23 ` Jeff King
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).