On Wed, Feb 23, 2011 at 12:11 PM, Johan Herland <johan@xxxxxxxxxxx> 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. -- 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