From: Johannes Sixt <johannes.sixt@telecom.at>
Date: Fri, 16 Feb 2007 23:30:03 GMT
Subject: Re: [PATCH] Fix incorrect diff of a link -> file change if core.filemode = false.
Message-ID: <200702170030.04014.johannes.sixt@telecom.at>
In-Reply-To: <7vejop1ysu.fsf@assigned-by-dhcp.cox.net>

On Saturday 17 February 2007 00:13, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> 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@telecom.at>
>
> 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