> Hi,
>
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
>
>> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
>> > From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> > cc: Alex Riesen <raa.lkml@gmail.com>,
ae@op5.se,
tsuna@lrde.epita.fr,
>> >
git@vger.kernel.org,
make-w32@gnu.org
>> >
>> > The problem is not so much opening, but determining if an existing file
>> > and a file in the index have the same name.
>> >
>> > For example, "README" in the index, but "readme" in the working directory,
>> > will be handled as "deleted/untracked" by the current machinery. IOW git
>> > will not know that what it gets from readdir() as "readme" really is the
>> > same file as "README" in the index.
>>
>> That's because you think file names are simple strings and can be
>> compared by simple string comparison.
>
> Almost...
>
>> This na?ve view is not true even on POSIX systems: "foo/bar" and
>> "/a/b/foo/bar" can be the same file, as well as "/a/b/c/d" and "/x/y/z",
>> given the right symlinks.
>
> ... not quite, ah ...
>
>> But for some reason that eludes me, people who are accustomed to POSIX
>> stop right there and in effect say "file names are strings, if we only
>> make them absolute and resolve links".
>
> ... yes! There you have it. Absolute filenames, resolved by
> readlink() are assumed to be the unique (!) identifiers for the
> contents.