git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Bug report about symlinks

From
René Scharfe <l.s.r@web.de>
Date
Aug 2, 2014, 14:10 UTC
Message-ID
<53DCF14D.8040705@web.de>
In-Reply-To
<xmqqppgkw55g.fsf@gitster.dls.corp.google.com>
Am 01.08.2014 um 18:23 schrieb Junio C Hamano:
Show 50 quoted lines
> René Scharfe <l.s.r@web.de> writes:
> 
>> # Create test repo with two directories with two files each.
>> $ git init
>> Initialized empty Git repository in /tmp/.git/
>> $ mkdir a b
>> $ echo x >a/equal
>> $ echo x >b/equal
>> $ echo y >a/different
>> $ echo z >b/different
>> $ git add a b
>> $ git commit -minitial
>> [master (root-commit) 6d36895] initial
>>   4 files changed, 4 insertions(+)
>>   create mode 100644 a/different
>>   create mode 100644 a/equal
>>   create mode 100644 b/different
>>   create mode 100644 b/equal
>>
>> # Replace one directory with a symlink to the other.
>> $ rm -rf b
>> $ ln -s a b
>>
>> # First git status call.
>> $ git status
>> On branch master
>> Changes not staged for commit:
>>    (use "git add/rm <file>..." to update what will be committed)
>>    (use "git checkout -- <file>..." to discard changes in working directory)
>>
>>          deleted:    b/different
>>
>> Untracked files:
>>    (use "git add <file>..." to include in what will be committed)
>>
>>          b
>>
>> no changes added to commit (use "git add" and/or "git commit -a")
>> ...
>>
>> It could be debated if the first git status call should also report
>> b/equal as deleted.
> 
> Hmph.
> 
> I wonder if "could be" is an understatement.  The difference of
> reporting between b/equal and b/different may indicate that somebody
> is mistakenly comparing the index with these paths, without first
> checking each path with has_symlink_leading_path(), or something,
> no?

How about the patch below? Before it checks if an index entry exists in the work tree, it checks if its path includes a symlink. After the patch, git status reports b/equal as deleted, too. The test suite still passes.

And do we need to use the threaded_ variant of the function here?
diff --git a/read-cache.c b/read-cache.c
index 5d3c8bd..6f0057f 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1064,6 +1064,14 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
 		return ce;
 	}
 
+	if (has_symlink_leading_path(ce->name, ce_namelen(ce))) {
+		if (ignore_missing)
+			return ce;
+		if (err)
+			*err = ENOENT;
+		return NULL;
+	}
+
 	if (lstat(ce->name, &st) < 0) {
 		if (ignore_missing && errno == ENOENT)
 			return ce;
Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 10 in “Bug report about symlinks”
  1. Nikolay AvdeevJul 31, 2014
  2. René ScharfeJul 31, 2014
  3. Junio C HamanoAug 1, 2014
  4. René ScharfeAug 2, 2014
  5. Junio C HamanoAug 3, 2014
  6. René ScharfeAug 3, 2014
  7. Junio C HamanoAug 4, 2014
  8. read-cache: check for leading symlinks when refreshing indexRené Scharfe, Aug 9, 2014
  9. Duy NguyenAug 4, 2014
  10. Junio C HamanoAug 4, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.