{"thread":{"id":"44164","subject":"git 2.9.2: is RUNTIME_PREFIX supposed to work?","startedAt":"2016-09-26T21:32:21Z","lastAt":"2016-09-27T16:37:44Z","messageCount":6,"participants":["Paul Smith","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"302640","messageId":"1474925524.4270.35.camel@mad-scientist.net","threadId":"44164","inReplyTo":null,"subject":"git 2.9.2: is RUNTIME_PREFIX supposed to work?","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2016-09-26T21:32:04Z","receivedAt":"2016-09-26T21:32:21Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"Hi all.  I'm trying to create a relocatable installation of Git 2.9.2,\nso I can copy it anywhere and it continues to run without any problem.\nThis is on GNU/Linux systems, FWIW.\n\nLooking through the code (for some other reason) I discovered the\nRUNTIME_PREFIX setting which appears to attempt to set up the system\npaths based on a prefix determined from the directory containing the\ngit command.  That looks like exactly what I want.\n\nIf I set RUNTIME_PREFIX=YesPlease and gitexecdir=libexec/git-core on\nthe make invocation, it appears to do the right thing when I invoke\n.../libexec/git-core/git, even if I move it around.  Cool!\n\nExcept, when it doesn't.  And when it doesn't is all the situations\nwhere Git runs subcommands: for example, \"git pull\" which wants to\ninvoke fetch and merge-base commands.\n\nWhen RUNTIME_PREFIX is defined, it's a requirement that the argv[0] for\nthe process be a fully-qualified pathname: if it's not, then git will\nassert at exec_cmd.c:23 in system_path():\n\n\tassert(argv0_path);\n\nThe argv0_path variable is set based on argv[0] passed in to main().\nWhen I invoke top-level Git commands, that value is a fully-qualified\npath just as you'd expect.  However, when Git itself invokes\nsubcommands it does so in a weird way where argv[0] is the command it\nwants to invoke, using the magical execv() facility that lets you\ninvoke a command while providing a different value as argv[0].\n\nFor example my core dump from the assert of the merge-base shows:\n\n  (gdb) p argv[0]\n  $2 = 0x7fffd70c338e \"merge-base\"\n  (gdb) p argv[1]\n  $3 = 0x7fffd70c3399 \"--fork-point\"\n  (gdb) p argv[2]\n  $4 = 0x7fffd70c33a6 \"refs/remotes/origin/master\"\n  (gdb) p argv[3]\n  $5 = 0x7fffd70c33c1 \"master\"\n\nLooking at builtin/pull.c I see get_rebase_fork_point() calls\ncapture_command() with this Git command, which calls start_command(),\nwhich calls execv_git_command(), which calls sane_execvp(), which\ninvokes \"git\" as the filename but with argv[0] as \"merge-base\":\n\n        sane_execvp(\"git\", (char **)nargv.argv);\n           ...calls sane_execvp():\n        if (!execvp(file, argv))\n                return 0; /* cannot happen ;-) */\n\nThis causes the assert.\n\nSo, my question is: is this a bug in RUNTIME_PREFIX support?  Or is\nRUNTIME_PREFIX no longer supported, or maybe not supported at all on\nUNIX-type operating systems?\n\nCheers!\n"},{"id":"302643","messageId":"CAPc5daU_nnHRjtC02bxqRaoU+0Rgi7pS6e912Fqk-Xy=qdKWFA@mail.gmail.com","threadId":"44164","inReplyTo":"1474925524.4270.35.camel@mad-scientist.net","subject":"Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-26T21:57:29Z","receivedAt":"2016-09-26T21:57:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith wrote:\n> Hi all. I'm trying to create a relocatable installation of Git 2.9.2,\n> so I can copy it anywhere and it continues to run without any problem.\n> This is on GNU/Linux systems, FWIW.\n\nI had an impression that the setting was only to support MS Windows.\n"},{"id":"302700","messageId":"1474982294.3190.32.camel@mad-scientist.net","threadId":"44164","inReplyTo":"CAPc5daU_nnHRjtC02bxqRaoU+0Rgi7pS6e912Fqk-Xy=qdKWFA@mail.gmail.com","subject":"Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2016-09-27T13:18:14Z","receivedAt":"2016-09-27T13:25:10Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:\n> On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith wrote:\n> > \n> > Hi all. I'm trying to create a relocatable installation of Git 2.9.2,\n> > so I can copy it anywhere and it continues to run without any problem.\n> > This is on GNU/Linux systems, FWIW.\n> \n> I had an impression that the setting was only to support MS Windows.\n\nHm.  You may be right.  If so that's too bad, because a relocatable Git\nis very handy even on UNIX systems.  Is there a reason for invoking the\nsubcommands by providing the plain command (\"fetch\", \"merge-base\") as\nargv[0], rather than giving the fully-qualified path to a Git command?\n"},{"id":"302710","messageId":"alpine.DEB.2.20.1609271732440.129229@virtualbox","threadId":"44164","inReplyTo":"1474982294.3190.32.camel@mad-scientist.net","subject":"Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-09-27T15:34:20Z","receivedAt":"2016-09-27T15:34:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Paul,\n\nOn Tue, 27 Sep 2016, Paul Smith wrote:\n\n> On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:\n> > On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith wrote:\n> > > \n> > > Hi all. I'm trying to create a relocatable installation of Git 2.9.2,\n> > > so I can copy it anywhere and it continues to run without any problem.\n> > > This is on GNU/Linux systems, FWIW.\n> > \n> > I had an impression that the setting was only to support MS Windows.\n> \n> Hm.  You may be right.  If so that's too bad, because a relocatable Git\n> is very handy even on UNIX systems.\n\nI see no reason why we have to keep the RUNTIME_PREFIX functional for\nWindows only. Paul, how about giving it a try to fix things? I can make\nsure that your changes do not break anything on Windows.\n\nCiao,\nJohannes"},{"id":"302714","messageId":"xmqqh991qpyn.fsf@gitster.mtv.corp.google.com","threadId":"44164","inReplyTo":"1474982294.3190.32.camel@mad-scientist.net","subject":"Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-27T16:15:12Z","receivedAt":"2016-09-27T16:15:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Smith writes:\n\n> On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:\n>> On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith wrote:\n>> > \n>> > Hi all. I'm trying to create a relocatable installation of Git 2.9.2,\n>> > so I can copy it anywhere and it continues to run without any problem.\n>> > This is on GNU/Linux systems, FWIW.\n>> \n>> I had an impression that the setting was only to support MS Windows.\n>\n> Hm. You may be right. If so that's too bad, because a relocatable Git\n> is very handy even on UNIX systems. Is there a reason for invoking the\n> subcommands by providing the plain command (\"fetch\", \"merge-base\") as\n> argv[0], rather than giving the fully-qualified path to a Git command?\n\nI do not think of any reason offhand. It just is that we never\nneeded it.\n\nIf you want to add support without making the resulting codebase too\nugly, without breaking the classic way of installing into a fixed\nlocations, and without breaking the existing support of platforms\nthat does know the runtime-prefix thing, not just I wouldn't mind\nbut I would welcome such an addition ;-)\n\nThanks.\n"},{"id":"302717","messageId":"xmqq8tudqoxm.fsf@gitster.mtv.corp.google.com","threadId":"44164","inReplyTo":"xmqqh991qpyn.fsf@gitster.mtv.corp.google.com","subject":"Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-27T16:37:25Z","receivedAt":"2016-09-27T16:37:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Paul Smith writes:\n>\n>> On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:\n>>> On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith wrote:\n>>> > \n>>> > Hi all. I'm trying to create a relocatable installation of Git 2.9.2,\n>>> > so I can copy it anywhere and it continues to run without any problem.\n>>> > This is on GNU/Linux systems, FWIW.\n>>> \n>>> I had an impression that the setting was only to support MS Windows.\n>>\n>> Hm. You may be right. If so that's too bad, because a relocatable Git\n>> is very handy even on UNIX systems. Is there a reason for invoking the\n>> subcommands by providing the plain command (\"fetch\", \"merge-base\") as\n>> argv[0], rather than giving the fully-qualified path to a Git command?\n>\n> I do not think of any reason offhand. It just is that we never\n> needed it.\n\nIf you are talking about invoking \"git-fetch\", then there is a very\ngood reason. Built-in's do not need any actual binary on the\nfilesystem (they only need \"git\").\n\nBut that does not have any relevance to the part below.\n\n> If you want to add support without making the resulting codebase too\n> ugly, without breaking the classic way of installing into a fixed\n> locations, and without breaking the existing support of platforms\n> that does know the runtime-prefix thing, not just I wouldn't mind\n> but I would welcome such an addition ;-)\n\nIf you can make runtime-prefix honored on more platforms, that would\nbe good, though you _might_ have just added another \"without\" to the\nabove list: without using full paths e.g. /usr/local/git/bin/git-fetch\nunconditionally.\n\n"}]}