git 2.9.2: is RUNTIME_PREFIX supposed to work?

Hi all.  I'm trying to create a relocatable installation of Git 2.9.2, so I can copy it anywhere and it continues to run without any problem. This is on GNU/Linux systems, FWIW.

Looking through the code (for some other reason) I discovered the RUNTIME_PREFIX setting which appears to attempt to set up the system paths based on a prefix determined from the directory containing the git command.  That looks like exactly what I want.

If I set RUNTIME_PREFIX=YesPlease and gitexecdir=libexec/git-core on the make invocation, it appears to do the right thing when I invoke .../libexec/git-core/git, even if I move it around.  Cool!

Except, when it doesn't.  And when it doesn't is all the situations where Git runs subcommands: for example, "git pull" which wants to invoke fetch and merge-base commands.

When RUNTIME_PREFIX is defined, it's a requirement that the argv[0] for the process be a fully-qualified pathname: if it's not, then git will assert at exec_cmd.c:23 in system_path():

	assert(argv0_path);

The argv0_path variable is set based on argv[0] passed in to main(). When I invoke top-level Git commands, that value is a fully-qualified path just as you'd expect.  However, when Git itself invokes subcommands it does so in a weird way where argv[0] is the command it wants to invoke, using the magical execv() facility that lets you invoke a command while providing a different value as argv[0].

For example my core dump from the assert of the merge-base shows:

  (gdb) p argv[0]
  $2 = 0x7fffd70c338e "merge-base"
  (gdb) p argv[1]
  $3 = 0x7fffd70c3399 "--fork-point"
  (gdb) p argv[2]
  $4 = 0x7fffd70c33a6 "refs/remotes/origin/master"
  (gdb) p argv[3]
  $5 = 0x7fffd70c33c1 "master"

Looking at builtin/pull.c I see get_rebase_fork_point() calls capture_command() with this Git command, which calls start_command(), which calls execv_git_command(), which calls sane_execvp(), which invokes "git" as the filename but with argv[0] as "merge-base":

        sane_execvp("git", (char **)nargv.argv);
           ...calls sane_execvp():
        if (!execvp(file, argv))
                return 0; /* cannot happen ;-) */

This causes the assert.

So, my question is: is this a bug in RUNTIME_PREFIX support?  Or is RUNTIME_PREFIX no longer supported, or maybe not supported at all on UNIX-type operating systems?

Cheers!

On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith <paul@mad-scientist.net> wrote:

I had an impression that the setting was only to support MS Windows.

On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:

Hm.  You may be right.  If so that's too bad, because a relocatable Git is very handy even on UNIX systems.  Is there a reason for invoking the subcommands by providing the plain command ("fetch", "merge-base") as argv[0], rather than giving the fully-qualified path to a Git command?

Hi Paul,

On Tue, 27 Sep 2016, Paul Smith wrote:

I see no reason why we have to keep the RUNTIME_PREFIX functional for Windows only. Paul, how about giving it a try to fix things? I can make sure that your changes do not break anything on Windows.

Ciao, Johannes

Paul Smith <paul@mad-scientist.net> writes:

I do not think of any reason offhand. It just is that we never needed it.

If you want to add support without making the resulting codebase too ugly, without breaking the classic way of installing into a fixed locations, and without breaking the existing support of platforms that does know the runtime-prefix thing, not just I wouldn't mind but I would welcome such an addition ;-)

Thanks.

Junio C Hamano <gitster@pobox.com> writes:

If you are talking about invoking "git-fetch", then there is a very good reason. Built-in's do not need any actual binary on the filesystem (they only need "git").

But that does not have any relevance to the part below.

If you can make runtime-prefix honored on more platforms, that would be good, though you _might_ have just added another "without" to the above list: without using full paths e.g. /usr/local/git/bin/git-fetch unconditionally.