Re: Git 2.18: RUNTIME_PREFIX... is it working?

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Paul,

On Sun, 8 Jul 2018, Paul Smith wrote:

> On Fri, 2018-07-06 at 09:18 -0400, Daniel Jacques wrote:
> > I forewent autoconf because I was concerned that the option was too
> > obscure and the configuration too nuanced to be worth adding via
> > flag, as RUNTIME_PREFIX requires some degree of path alignment and is
> > fairly special-case. If you prefer autoconf, though, it sounds like a
> > good thing to add, and I'm happy that you are finding the feature
> > useful!
> 
> Well, far from obscure, I actually think that RUNTIME_PREFIX should be
> the default behavior on all platforms.  In fact speaking for myself, I
> see no value at all in the hardcoded path behavior and it could be
> removed and RUNTIME_PREFIX be the only option and that would be fine
> with me.
> 
> The only possible advantage I can see to the current default that you
> can copy the Git binary alone somewhere else, but that's of very little
> value IMO: you could instead create a symbolic link or a two-line shell
> script wrapper if you wanted to have "git" available outside of its
> normal relation to the rest of the installation for some reason.

In theory, I agree with you, I would love for RUNTIME_PREFIX not even to
be needed.

In practice, however, a *loooong* time ago it was decided that it was okay
to implement parts of Git as shell scripts, and when those shell scripts
finally became too many, in order not to clutter the `PATH`, they were
moved to the libexec/git-core/ directory.

Obviously, for this to work, Git needs to prefix the `PATH` variable
internally, and for that it has to know where that libexec/git-core/
directory lives.

Now, if you care to have a look at Dan's (and my) patches to implement
RUNTIME_PREFIX so that it looks for a directory *relative to the Git
binary*, you will see that it is far from portable. In fact, it is very
definitely not portable, and needs specific support for *every single
supported Operating System*. And while we covered a lot, we did not cover
all of them.

So unfortunately, it is impossible to make it the default, I am afraid.
Until the time when we can ship a single `git` binary (which is sadly
unlikely to happen, as there has been a *lot* of pushback against that
e.g. on the grounds that having to (lazy-)load the cURL library adds a
tiny bit to the startup time of the `git` binary).

It is all a bit complex, due to non-technical reasons.

Ciao,
Dscho