git 2.9.2: is RUNTIME_PREFIX supposed to work?

git 2.9.2: is RUNTIME_PREFIX supposed to work?

[Paul Smith]

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!

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

[Junio C Hamano]

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

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

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

[Paul Smith]

On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:
> On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith <paul@mad-scientist.net> wrote:
> > 
> > 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.
> 
> I had an impression that the setting was only to support MS Windows.

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?

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Hi Paul,

On Tue, 27 Sep 2016, Paul Smith wrote:

> On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:
> > On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith <paul@mad-scientist.net> wrote:
> > > 
> > > 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.
> > 
> > I had an impression that the setting was only to support MS Windows.
> 
> Hm.  You may be right.  If so that's too bad, because a relocatable Git
> is very handy even on UNIX systems.

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

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

[Junio C Hamano]

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

> On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:
>> On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith <paul@mad-scientist.net> wrote:
>> > 
>> > 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.
>> 
>> I had an impression that the setting was only to support MS Windows.
>
> 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?

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.

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

[Junio C Hamano]

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

> Paul Smith <paul@mad-scientist.net> writes:
>
>> On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:
>>> On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith <paul@mad-scientist.net> wrote:
>>> > 
>>> > 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.
>>> 
>>> I had an impression that the setting was only to support MS Windows.
>>
>> 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?
>
> I do not think of any reason offhand. It just is that we never
> needed it.

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 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 ;-)

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.