{"thread":{"id":"52714","subject":"packObjectsHook and the git executable","startedAt":"2020-01-30T01:00:32Z","lastAt":"2020-01-30T08:23:56Z","messageCount":4,"participants":["Bryan Turner","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"390759","messageId":"CAGyf7-E==gzsvP-ckK0kwHD+f9pMmLBVpL4y2rC9tqk7ZiuW1g@mail.gmail.com","threadId":"52714","inReplyTo":null,"subject":"packObjectsHook and the git executable","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2020-01-30T01:00:18Z","receivedAt":"2020-01-30T01:00:32Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"In upload-pack.c, when Git invokes the packObjectsHook, it's\nhard-coded to pass \"git\". Unless it modifies the PATH environment\nvariable, though, if the script were to invoke the provided command\nline as-is, it may end up running a different version of Git than the\nversion being used to run upload-pack (or http-backend).\n\nIs there any way the packObjectsHook could be passed the \"right\" git\nexecutable? Or am I missing some surrounding context that means\nexecuting \"git\" is somehow guaranteed to invoke the \"right\" binary?\n(Perhaps this same PATH-related caveat applies to other places where\nGit invokes itself recursively?)\n\nGrateful for any insight!\nBryan\n"},{"id":"390768","messageId":"20200130071102.GA2189233@coredump.intra.peff.net","threadId":"52714","inReplyTo":"CAGyf7-E==gzsvP-ckK0kwHD+f9pMmLBVpL4y2rC9tqk7ZiuW1g@mail.gmail.com","subject":"Re: packObjectsHook and the git executable","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-30T07:11:02Z","receivedAt":"2020-01-30T07:11:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 29, 2020 at 05:00:18PM -0800, Bryan Turner wrote:\n\n> In upload-pack.c, when Git invokes the packObjectsHook, it's\n> hard-coded to pass \"git\". Unless it modifies the PATH environment\n> variable, though, if the script were to invoke the provided command\n> line as-is, it may end up running a different version of Git than the\n> version being used to run upload-pack (or http-backend).\n\nWe do modify PATH to put git's exec-path at the start. This happens in\nsetup_path(), which is called by the main \"git\" executable (so \"git\nupload-pack\" before it hits cmd_upload_pack()).\n\nPrograms which are invoked directly as \"git-upload-pack\" need to call\nthat function on their own (which happens when upload-pack is invoked\nover ssh). But upload-pack and http-backend do that.\n\n> Is there any way the packObjectsHook could be passed the \"right\" git\n> executable? Or am I missing some surrounding context that means\n> executing \"git\" is somehow guaranteed to invoke the \"right\" binary?\n> (Perhaps this same PATH-related caveat applies to other places where\n> Git invokes itself recursively?)\n\nI think all is working as designed, but if you have a reproducible case\nwhere we run the \"wrong\" git, I can take a look at it.\n\n-Peff\n"},{"id":"390773","messageId":"CAGyf7-HkUV43A79DKiDVvKnW5vuwsFz0KnZKj9bBQYc906VONg@mail.gmail.com","threadId":"52714","inReplyTo":"20200130071102.GA2189233@coredump.intra.peff.net","subject":"Re: packObjectsHook and the git executable","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2020-01-30T07:38:23Z","receivedAt":"2020-01-30T07:38:37Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Wed, Jan 29, 2020 at 11:11 PM Jeff King <peff@peff.net> wrote:\n>\n> On Wed, Jan 29, 2020 at 05:00:18PM -0800, Bryan Turner wrote:\n>\n> > In upload-pack.c, when Git invokes the packObjectsHook, it's\n> > hard-coded to pass \"git\". Unless it modifies the PATH environment\n> > variable, though, if the script were to invoke the provided command\n> > line as-is, it may end up running a different version of Git than the\n> > version being used to run upload-pack (or http-backend).\n>\n> We do modify PATH to put git's exec-path at the start. This happens in\n> setup_path(), which is called by the main \"git\" executable (so \"git\n> upload-pack\" before it hits cmd_upload_pack()).\n\nThanks, that's a missing piece I'd overlooked (and explains why\neverything is written the way it is, to use \"git\").\n\n>\n> Programs which are invoked directly as \"git-upload-pack\" need to call\n> that function on their own (which happens when upload-pack is invoked\n> over ssh). But upload-pack and http-backend do that.\n>\n> > Is there any way the packObjectsHook could be passed the \"right\" git\n> > executable? Or am I missing some surrounding context that means\n> > executing \"git\" is somehow guaranteed to invoke the \"right\" binary?\n> > (Perhaps this same PATH-related caveat applies to other places where\n> > Git invokes itself recursively?)\n>\n> I think all is working as designed, but if you have a reproducible case\n> where we run the \"wrong\" git, I can take a look at it.\n\nI suspect it's a case of a broken Git build. Not that Git is doing\nanything wrong, or has any problems with its build, to be clear--I\nmean instead that someone ran a local build and didn't set it up\n\"right\". Correct me if I'm wrong but:\n- If the GIT_EXEC_PATH environment variable isn't set, Git will use\nthe path that was compiled in when it was built\n- If that Git is installed in a different path (i.e. compiled for\n/usr/local but installed in /opt), the compiled-in exec path may not\nexist or not contain \"git\"\n- In that case, \"git\" gets run from wherever it's found in $PATH and\nyou get whatever version that happens to be\n\nDoes something like that seem like it could happen?\n\nThanks as always for your insights!\nBryan\n\n>\n> -Peff\n"},{"id":"390774","messageId":"20200130082353.GA3442119@coredump.intra.peff.net","threadId":"52714","inReplyTo":"CAGyf7-HkUV43A79DKiDVvKnW5vuwsFz0KnZKj9bBQYc906VONg@mail.gmail.com","subject":"Re: packObjectsHook and the git executable","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-30T08:23:53Z","receivedAt":"2020-01-30T08:23:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 29, 2020 at 11:38:23PM -0800, Bryan Turner wrote:\n\n> I suspect it's a case of a broken Git build. Not that Git is doing\n> anything wrong, or has any problems with its build, to be clear--I\n> mean instead that someone ran a local build and didn't set it up\n> \"right\". Correct me if I'm wrong but:\n> - If the GIT_EXEC_PATH environment variable isn't set, Git will use\n> the path that was compiled in when it was built\n> - If that Git is installed in a different path (i.e. compiled for\n> /usr/local but installed in /opt), the compiled-in exec path may not\n> exist or not contain \"git\"\n> - In that case, \"git\" gets run from wherever it's found in $PATH and\n> you get whatever version that happens to be\n> \n> Does something like that seem like it could happen?\n\nYes, that's quite plausible. One easy way to trigger that is to run Git\nout of the build directory without a \"make install\". That's why we have\nthe bin-wrappers/ subdirectory, which sets up the exec-path to use the\nbuilt-but-not-installed version (and that's what we use when running the\ntest suite).\n\n-Peff\n"}]}