On Saturday 17 February 2007 00:13, Junio C Hamano wrote: > Johannes Sixt <johannes.sixt@xxxxxxxxxx> writes: > > After this sequence: > > > > $ ln -s foo A > > $ git add A > > $ git commit -m link > > $ rm A && echo bar > A > > > > the working copy contains a regular file A but HEAD contains A as a link. > > > > Normally, at this point 'git diff HEAD' displays this change as a removal > > of the link followed by an addition of a new file. But in a repository > > where core.filemode is false this is displayed as a modification of the > > link. The reason is that the check when the cached mode is allowed to > > override the file's actual mode is not strict enough. > > > > Signed-off-by: Johannes Sixt <johannes.sixt@xxxxxxxxxx> > > I do not follow. core.filemode aka trust_executable_bit is > about executable bit and not symlink. Correct. But the breakage is still there. As you recall, the properties S_IFREG and S_IFLNK are recorded in the st_mode, and the line of code that I fixed trusts the index in too many cases, and copies the index's S_IFLNK over the the stat() result, which said S_IFREG. So the diff engine loses the information that it is should diff against a regular file, and thinks that the working copy is a symlink. Please change the last sentence of the commit message, which hopefully makes the issue a bit clearer: The fix is that the cached mode must only be allowed to override the file's actual mode (which includes the type information) if _both_ the working tree entry and the cached entry are regular files. -- Hannes - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html