Thread (1 message) 1 message, 1 author, 2016-09-27

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

From: Junio C Hamano <hidden>
Date: 2016-09-27 16:37:44

Junio C Hamano [off-list ref] writes:
Paul Smith [off-list ref] writes:
quoted
On Mon, 2016-09-26 at 14:57 -0700, Junio C Hamano wrote:
quoted
On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help