Re: Can't handle renamed resources on case insensitive filesystems.
- From
Erik Faye-Lund <kusmabite@googlemail.com>
- Date
- Dec 14, 2009, 15:42 UTC
- Message-ID
- <40aa078e0912140742y1e20c155w5f0d1707a4c2ef5e@mail.gmail.com>
- In-Reply-To
- <40aa078e0912140650t7e061da0nfc75955cb584f3ba@mail.gmail.com>
On Mon, Dec 14, 2009 at 3:50 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
Show 21 quoted lines
> On Mon, Dec 14, 2009 at 3:27 PM, Lhunath (Maarten B.) <lhunath@gmail.com> 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. >
After doing a quick test, it seems no change are required for the git mv case: use the -f flag when renaming to turn the error into a warning. Of course, you should only do this when you know that you really want to rename the file. The following worked for me:
$ git init $ touch.exe test.txt $ git add test.txt $ git commit -m "initial commit" [master (root-commit) 5acb06f] initial commit 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 test.txt $ git mv test.txt Test.txt fatal: destination exists, source=test.txt, destination=Test.txt $ git mv test.txt Test.txt -f Warning: destination exists; will overwrite! $ ls Test.txt
I've only tested this on Windows, but I guess it should work on OSX as well.
-- Erik "kusma" Faye-Lund