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!
