Re: RFD: Handling case-colliding filenames on case-insensitive filesystems

On Wed, Feb 23, 2011 at 12:11 PM, Johan Herland [off-list ref] wrote:

A colleague suggested instead that Git should notice that the collision
will occur, and work around the failure to represent the repository
objects in the file system with a one-to-one match. Either by checking
out only _one_ of the colliding files, or by using a non-colliding name
for the second file. After all, Git already has functionality for
manipulating the file contents on checkout (CRLF conversion). Doesn't
it make sense to add functionality for manipulating the _directory_
contents on checkout as well? Even if that makes sense, I'm not sure
that implementing it will be straightforward.

Are there better suggestions on how to deal with this?

The general problem is aliasing in the working-tree, of which
case-insenitivity is the most common form, but it also happens due to
HFS's use of NFD. A search on gmane for "insensitive" or "nfd" will
return many hits.

I think the argument against remapping filenames is that it doesn't
really help the user.

Let's say (for the sake of argument) that git supported remapping
between the index and the working-tree. Further, my repo has:

$ cat Foo.c
#include "Foo.h"

$ cat foo.c
#include "foo.h"

And on a case-insensitive file-system, git has remapped foo.[ch] to
foo~2.[ch] for the purposes of avoiding collisions on checkout.

The checkout can't be compiled correctly, so what's the point of even
allowing it?

(I'm not saying this is right/wrong, just that's been one of the
arguments against remapping.)

j.