git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Ramsay Jones <ramsay@ramsayjones.plus.com>,
	Duy Nguyen <pclouds@gmail.com>,
	Junio C Hamano <gitster@pobox.com>, Johannes Sixt <j6t@kdbg.org>,
	Jeff King <peff@peff.net>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: [PATCH v2 2/2] expand_user_path(): support specifying paths relative to the runtime prefix
Date: Thu, 01 Jul 2021 16:03:07 +0000	[thread overview]
Message-ID: <66df56f5db02fa43b28111bb9fcc9b06f8542154.1625155388.git.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.66.v2.git.1625155388.gitgitgadget@gmail.com>

From: Johannes Schindelin <johannes.schindelin@gmx.de>

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@gmx.de>
---
 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

  parent reply	other threads:[~2021-07-01 16:03 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06 14:53 [PATCH 0/1] mingw: handle absolute paths in expand_user_path() Johannes Schindelin via GitGitGadget
2018-11-06 14:53 ` [PATCH 1/1] " Johannes Schindelin via GitGitGadget
2018-11-06 15:54   ` Ramsay Jones
2018-11-06 16:10     ` Ramsay Jones
2018-11-06 18:27       ` Duy Nguyen
2018-11-07  1:21     ` Junio C Hamano
2018-11-07 11:19       ` Johannes Schindelin
2018-11-07 17:42         ` Ramsay Jones
2018-11-08  0:16           ` Junio C Hamano
2018-11-08 13:04             ` Johannes Schindelin
2018-11-08 14:43               ` Junio C Hamano
2018-11-08 15:39                 ` Johannes Schindelin
2018-11-09  2:05             ` Joseph Moisan
2018-11-09 10:21               ` Jeff King
2018-11-06 18:24   ` Duy Nguyen
2018-11-07 11:19     ` Johannes Schindelin
2018-11-06 21:32   ` Johannes Sixt
2018-11-07 11:23     ` Johannes Schindelin
2018-11-07 18:52       ` Johannes Sixt
2018-11-07 20:41         ` Jeff King
2018-11-07 21:36           ` Johannes Sixt
2018-11-07 22:03             ` Jeff King
2018-11-08  0:30               ` Junio C Hamano
2018-11-08  1:18                 ` Jeff King
2018-11-08  3:26                   ` Junio C Hamano
2018-11-08 13:11               ` Johannes Schindelin
2018-11-08 14:25                 ` Duy Nguyen
2018-11-08 15:45                   ` Johannes Schindelin
2018-11-08 17:40                     ` Eric Sunshine
2018-11-09 10:19                     ` Jeff King
2018-11-09 16:16                       ` Duy Nguyen
2018-11-12  3:03                         ` Junio C Hamano
2018-11-08 14:47                 ` Junio C Hamano
2018-11-08 15:46                   ` Johannes Schindelin
2021-07-01 16:03 ` [PATCH v2 0/2] " Johannes Schindelin via GitGitGadget
2021-07-01 16:03   ` [PATCH v2 1/2] tests: exercise the RUNTIME_PREFIX feature Johannes Schindelin via GitGitGadget
2021-07-01 16:03   ` Johannes Schindelin via GitGitGadget [this message]
2021-07-01 17:42   ` [PATCH v2 0/2] mingw: handle absolute paths in expand_user_path() Junio C Hamano
2021-07-24 22:06   ` [PATCH v3 0/5] " Johannes Schindelin via GitGitGadget
2021-07-24 22:06     ` [PATCH v3 1/5] tests: exercise the RUNTIME_PREFIX feature Johannes Schindelin via GitGitGadget
2021-07-24 22:06     ` [PATCH v3 2/5] expand_user_path(): remove stale part of the comment Johannes Schindelin via GitGitGadget
2021-07-24 22:06     ` [PATCH v3 3/5] expand_user_path(): clarify the role of the `real_home` parameter Johannes Schindelin via GitGitGadget
2021-07-24 22:06     ` [PATCH v3 4/5] Use a better name for the function interpolating paths Johannes Schindelin via GitGitGadget
2021-07-26 22:05       ` Junio C Hamano
2021-07-27  7:57         ` Fabian Stelzer
2021-07-27 22:56           ` Junio C Hamano
2021-07-28  0:14             ` Junio C Hamano
2021-07-28  0:39               ` Junio C Hamano
2021-07-28  5:43                 ` Junio C Hamano
2021-07-28  8:18                   ` Fabian Stelzer
2021-07-28 17:08                     ` Junio C Hamano
2021-07-24 22:06     ` [PATCH v3 5/5] interpolate_path(): allow specifying paths relative to the runtime prefix Johannes Schindelin via GitGitGadget
2021-07-26 17:56     ` [PATCH v3 0/5] mingw: handle absolute paths in expand_user_path() Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66df56f5db02fa43b28111bb9fcc9b06f8542154.1625155388.git.gitgitgadget@gmail.com \
    --to=gitgitgadget@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=ramsay@ramsayjones.plus.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).