[PATCH] setup: translate symlinks in filename when using absolute paths

Previous thread: False positives in git diff-index by Alexander Gladysh on Monday, December 27, 2010 - 1:49 am. (6 messages)

Next thread: git-svn bug: Could not unmemoize function `lookup_svn_merge' ... by George V. Reilly on Monday, December 27, 2010 - 10:37 pm. (1 message)
From: Carlo Marcelo Arenas Belon
Date: Monday, December 27, 2010 - 3:54 am

otherwise, comparison to validate against work tree will fail when
the path includes a symlink and the name passed is not canonical.

Signed-off-by: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
---
 setup.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/setup.c b/setup.c
index 91887a4..e7c0d4d 100644
--- a/setup.c
+++ b/setup.c
@@ -7,10 +7,13 @@ static int inside_work_tree = -1;
 char *prefix_path(const char *prefix, int len, const char *path)
 {
 	const char *orig = path;
-	char *sanitized = xmalloc(len + strlen(path) + 1);
-	if (is_absolute_path(orig))
-		strcpy(sanitized, path);
-	else {
+	char *sanitized;
+	if (is_absolute_path(orig)) {
+		const char *temp = make_absolute_path(path);
+		sanitized = xmalloc(len + strlen(temp) + 1);
+		strcpy(sanitized, temp);
+	} else {
+		sanitized = xmalloc(len + strlen(path) + 1);
 		if (len)
 			memcpy(sanitized, prefix, len);
 		strcpy(sanitized + len, path);
-- 
1.7.3.4.626.g73e7b.dirty

--

From: Junio C Hamano
Date: Tuesday, December 28, 2010 - 12:47 pm

I take that "path" and "name passed" refer to the same thing (i.e. "path"
parameter) in the above.

I think you are trying to handle the case where:

 - you give "/home/carenas/one" from the command line;
 - $PWD is "/home/carenas"; and
 - "/home/carenas" is a symlink to "/net/host/home/carenas"

and the scan-from-the-beginning-of-string check done between
"/home/carenas/one" and the return value of get_git_work_tree() which
presumably is "/net/host/home/carenas" disagrees.  I wonder if a more
correct solution might be to help get_git_work_tree() to match the notion
of where the repository and its worktree are to the idea of where the user
thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a
bit better?

That would involve tweaking make_absolute_path() I guess?

Note that your patch is the right thing to do either case, i.e. with or
without such a change to make_absolute_path(), as the function is used to
set up the return value from get_git_work_tree().  Anything we compare
with it should have passed make_absolute_path() at least once.

--

From: Carlo Marcelo Arenas Belon
Date: Wednesday, December 29, 2010 - 2:35 am

yes, and sorry for the cryptic description; you detailed below though this
is triggered by the fact that when using an absolute path filename as a
parameter detection for worktree is failing because it was normalized

this will be a valid  scenario, but the issue (with a different use case)
was reported in (which I missed to refer to when running git send-email):


are you suggesting symlinks would be left untouched at least during
resolution for work_dir?, why is even necesary to resolve the links for
other users of that function?

Carlo
--

From: Nguyen Thai Ngoc Duy
Date: Wednesday, December 29, 2010 - 6:44 am

Hm.. can we avoid converting work_tree to absolute path unless people
explicitly set it (via --work-tree and GIT_WORK_TREE)? Basically
worktree will be relative to cwd. Usually it's just ".". When people
run commands outside worktree, it's the relative "cwd/to/worktree".
I'm wondering if we can just avoid the use of make_absolute_path()

Yes, I think that should that be done inside normalize_path_copy(),

Also Carlo, tests should be good for illustration and regression
purposes. I know you described in detail in another mail. But mails
tend to get lost.
-- 
Duy
--

Previous thread: False positives in git diff-index by Alexander Gladysh on Monday, December 27, 2010 - 1:49 am. (6 messages)

Next thread: git-svn bug: Could not unmemoize function `lookup_svn_merge' ... by George V. Reilly on Monday, December 27, 2010 - 10:37 pm. (1 message)