{"thread":{"id":"21952","subject":"Can't handle renamed resources on case insensitive filesystems.","startedAt":"2009-12-14T14:27:30Z","lastAt":"2009-12-14T15:42:53Z","messageCount":4,"participants":["Lhunath (Maarten B.)","Erik Faye-Lund","Tomas Carnecky"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"129877","messageId":"63135FDB-C8EF-4DBC-AEF5-4B0636C8D349@gmail.com","threadId":"21952","inReplyTo":null,"subject":"Can't handle renamed resources on case insensitive filesystems.","fromName":"Lhunath (Maarten B.)","fromEmail":"lhunath@gmail.com","sentAt":"2009-12-14T14:27:30Z","receivedAt":"2009-12-14T14:27:30Z","isPatch":false,"sender":{"key":"lhunath@gmail.com","avatar":"https://gravatar.com/avatar/bc5b6a8b0cdd6a29c7019afb479286896c37dd293484d641de4bdb186f8a9f80?d=mp&s=160"},"body":"GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.\n\nFor instance:\n\nlhunath@Myst t $ git mv Foo foo\nfatal: destination exists, source=Foo, destination=foo\n\nMoreover, 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.\n\nMost 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).\n\nIn 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."},{"id":"129878","messageId":"40aa078e0912140650t7e061da0nfc75955cb584f3ba@mail.gmail.com","threadId":"21952","inReplyTo":"63135FDB-C8EF-4DBC-AEF5-4B0636C8D349@gmail.com","subject":"Re: Can't handle renamed resources on case insensitive filesystems.","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-12-14T14:50:16Z","receivedAt":"2009-12-14T14:50:16Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Dec 14, 2009 at 3:27 PM, Lhunath (Maarten B.) <lhunath@gmail.com> wrote:\n> GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.\n>\n> For instance:\n>\n> lhunath@Myst t $ git mv Foo foo\n> fatal: destination exists, source=Foo, destination=foo\n>\n> 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.\n>\n> 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).\n>\n> 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.--\n\nActually, you have only discovered the tip of the iceberg that is git\nand case insensitivity. However, it is probably also the most annoying\npart of it. Changing git mv to skip moving (or moving in a way that\nworks better) the file when core.ignorecase is enabled and the source\nand destination are the same when compared in a case insensitive\nfashion might make sense.\n\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"129879","messageId":"4B26511F.5040804@dbservice.com","threadId":"21952","inReplyTo":"63135FDB-C8EF-4DBC-AEF5-4B0636C8D349@gmail.com","subject":"Re: Can't handle renamed resources on case insensitive filesystems.","fromName":"Tomas Carnecky","fromEmail":"tom@dbservice.com","sentAt":"2009-12-14T14:52:15Z","receivedAt":"2009-12-14T14:52:15Z","isPatch":false,"sender":{"key":"tom@dbservice.com","avatar":"https://gravatar.com/avatar/900a300bdd1a8bbe086008ad78210bbee2ad2803b7d50a5cba04c1e9404bd6d2?d=mp&s=160"},"body":"On 12/14/09 3:27 PM, Lhunath (Maarten B.) wrote:\n> GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.\n>\n> For instance:\n>\n> lhunath@Myst t $ git mv Foo foo\n> fatal: destination exists, source=Foo, destination=foo\n>\n> 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.\n>\n> 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).\n>\n> 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.--\n\nCreate a disk image and format it with case-sensitive HFS+, create a new \npartition and format it with case-sensitive HFS+, or reinstall Mac OS X \nand choose case-sensitive HFS+ as the filesystem for the system partition.\n\nAfter I found out that the default install of Mac OS X uses \ncase-insensitive filesystem, the first thing I did was reinstall the OS.\n\ntom\n"},{"id":"129881","messageId":"40aa078e0912140742y1e20c155w5f0d1707a4c2ef5e@mail.gmail.com","threadId":"21952","inReplyTo":"40aa078e0912140650t7e061da0nfc75955cb584f3ba@mail.gmail.com","subject":"Re: Can't handle renamed resources on case insensitive filesystems.","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-12-14T15:42:53Z","receivedAt":"2009-12-14T15:42:53Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Dec 14, 2009 at 3:50 PM, Erik Faye-Lund\n<kusmabite@googlemail.com> wrote:\n> On Mon, Dec 14, 2009 at 3:27 PM, Lhunath (Maarten B.) <lhunath@gmail.com> wrote:\n>> GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.\n>>\n>> For instance:\n>>\n>> lhunath@Myst t $ git mv Foo foo\n>> fatal: destination exists, source=Foo, destination=foo\n>>\n>> 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.\n>>\n>> 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).\n>>\n>> 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.--\n>\n> Actually, you have only discovered the tip of the iceberg that is git\n> and case insensitivity. However, it is probably also the most annoying\n> part of it. Changing git mv to skip moving (or moving in a way that\n> works better) the file when core.ignorecase is enabled and the source\n> and destination are the same when compared in a case insensitive\n> fashion might make sense.\n>\n\nAfter doing a quick test, it seems no change are required for the git\nmv case: use the -f flag when renaming to turn the error into a\nwarning. Of course, you should only do this when you know that you\nreally want to rename the file. The following worked for me:\n\n$ git init\n$ touch.exe test.txt\n$ git add test.txt\n$ git commit -m \"initial commit\"\n[master (root-commit) 5acb06f] initial commit\n 0 files changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 test.txt\n$ git mv test.txt Test.txt\nfatal: destination exists, source=test.txt, destination=Test.txt\n$ git mv test.txt Test.txt -f\nWarning: destination exists; will overwrite!\n$ ls\nTest.txt\n\nI've only tested this on Windows, but I guess it should work on OSX as well.\n\n-- \nErik \"kusma\" Faye-Lund\n"}]}