From: Johannes Schindelin <johannes.schindelin@xxxxxx>
Ever since Git learned to detect its install location at runtime, there
was the slightly awkward problem that it was impossible to specify paths
relative to said location.
For example, if a version of Git was shipped with custom SSL
certificates to use, there was no portable way to specify
`http.sslCAInfo`.
In Git for Windows, the problem was "solved" for years by interpreting
paths starting with a slash as relative to the runtime prefix.
However, this is not correct: such paths _are_ legal on Windows, and
they are interpreted as absolute paths in the same drive as the current
directory.
After a lengthy discussion, and a way lengthier time to mull over the
problem and its best solution, we decided to introduce support for the
magic sequence `<RUNTIME-PREFIX>/`. If a path starts with this, the
remainder is interpreted as relative to the detected runtime prefix.
This solves the problem, but what new problems does it stir up? Here are
the two most obvious ones:
- What if Git was not compiled with support for a runtime prefix?
In that case, we will simply use the compiled-in hard-coded prefix.
- What if a user _wants_ to specify a path starting with the magic
sequence?
In that case, the user will simply need to prefix the magic sequence
with `./` and voilà, the path won't be expanded.
Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
---
Documentation/config.txt | 10 ++++++++++
path.c | 5 +++++
t/t0060-path-utils.sh | 8 ++++++++
3 files changed, 23 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf82766a6a2..fd56e2c1220 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -298,6 +298,16 @@ pathname::
tilde expansion happens to such a string: `~/`
is expanded to the value of `$HOME`, and `~user/` to the
specified user's home directory.
++
+If a path starts with `<RUNTIME-PREFIX>/`, the remainder is
+interpreted as a path relative to Git's "runtime prefix", i.e. relative
+to the location where Git itself was installed. For example,
+`<RUNTIME-PREFIX>/bin/` refers to the directory in which the Git
+executable itself lives. If Git was compiled without runtime prefix
+support, the compiled-in prefix will be subsituted instead. In the
+unlikely event that a literal path needs to be specified that should
+_not_ be expanded, it needs to be prefixed by `./`, like so:
+`./<RUNTIME-PREFIX>/bin`.
Variables
diff --git a/path.c b/path.c
index 7bccd830e95..d8542a7b27b 100644
--- a/path.c
+++ b/path.c
@@ -12,6 +12,7 @@
#include "packfile.h"
#include "object-store.h"
#include "lockfile.h"
+#include "exec-cmd.h"
static int get_st_mode_bits(const char *path, int *mode)
{
@@ -732,6 +733,10 @@ char *expand_user_path(const char *path, int real_home)
if (path == NULL)
goto return_null;
+
+ if (skip_prefix(path, "<RUNTIME-PREFIX>/", &path))
+ return system_path(path);
+
if (path[0] == '~') {
const char *first_slash = strchrnul(path, '/');
const char *username = path + 1;
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index a76728c27bf..cb7fbfb9af2 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -540,6 +540,14 @@ test_expect_success RUNTIME_PREFIX,CAN_EXEC_IN_PWD 'RUNTIME_PREFIX works' '
cp "$GIT_EXEC_PATH"/git$X pretend/bin/ &&
GIT_EXEC_PATH= ./pretend/bin/git here >actual &&
echo HERE >expect &&
+ test_cmp expect actual'
+
+test_expect_success RUNTIME_PREFIX,CAN_EXEC_IN_PWD '<RUNTIME-PREFIX>/ works' '
+ mkdir -p pretend/bin &&
+ cp "$GIT_EXEC_PATH"/git$X pretend/bin/ &&
+ git config yes.path "<RUNTIME-PREFIX>/yes" &&
+ GIT_EXEC_PATH= ./pretend/bin/git config --path yes.path >actual &&
+ echo "$(pwd)/pretend/yes" >expect &&
test_cmp expect actual
'
--
gitgitgadget
