From: Paul Smith <paul@mad-scientist.net>
Date: Mon, 26 Sep 2016 21:32:04 GMT
Subject: git 2.9.2: is RUNTIME_PREFIX supposed to work?
Message-ID: <1474925524.4270.35.camel@mad-scientist.net>

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!