On Mon, Dec 14, 2009 at 3:27 PM, Lhunath (Maarten B.) <lhunath@xxxxxxxxx> wrote: > GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+. > > For instance: > > lhunath@Myst t $ git mv Foo foo > fatal: destination exists, source=Foo, destination=foo > > Moreover, when a repository contains Foo and foo in one commit and in a subsequent commit, "foo" is removed; "Foo" will also disappear when checking out the latter. > > Most of these issues are likely just a result of the underlying file system's handling of GIT's commands; though considering that Mac OS X's default fs is case insensitive by default, and the Mac and Windows userbases combined are quite large; it might be very much appropriate to do a check for this (if needed) and handle renames (and other operations?) in a way that they would not cause conflicts on these file systems (eg. rename to a temporary filename first and then rename to destination). > > In particular; these issues make it awfully painful to refactor Java class names from things like JndiUtils -> JNDIUtils. Not only is it hard to get the commit INTO the repository correctly; it is also hard to check the commit OUT for somebody who has no idea any of this is needed.-- Actually, you have only discovered the tip of the iceberg that is git and case insensitivity. However, it is probably also the most annoying part of it. Changing git mv to skip moving (or moving in a way that works better) the file when core.ignorecase is enabled and the source and destination are the same when compared in a case insensitive fashion might make sense. -- Erik "kusma" Faye-Lund -- 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