threads / discuss / 21952

Can't handle renamed resources on case insensitive filesystems.

Subject: Can't handle renamed resources on case insensitive filesystems.

## tl;dr

4 messages between Dec 14, 2009 and Dec 14, 2009.

replies: 3people: 3as markdown or json

Lhunath (Maarten B.)· Dec 14, 2009, 14:27 UTC · lore
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.
Erik Faye-Lund· Dec 14, 2009, 14:50 UTC · re: Lhunath (Maarten B.) · lore

Re: Can't handle renamed resources on case insensitive filesystems.

On Mon, Dec 14, 2009 at 3:27 PM, Lhunath (Maarten B.) <lhunath@gmail.com> wrote:
Show 12 quoted lines
> 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
Erik Faye-Lund· Dec 14, 2009, 15:42 UTC · re: Erik Faye-Lund · lore

Re: Can't handle renamed resources on case insensitive filesystems.

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
Tomas Carnecky· Dec 14, 2009, 14:52 UTC · re: Lhunath (Maarten B.) · lore

Re: Can't handle renamed resources on case insensitive filesystems.

On 12/14/09 3:27 PM, Lhunath (Maarten B.) wrote:
Show 12 quoted lines
> 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.--

Create a disk image and format it with case-sensitive HFS+, create a new partition and format it with case-sensitive HFS+, or reinstall Mac OS X and choose case-sensitive HFS+ as the filesystem for the system partition.

After I found out that the default install of Mac OS X uses case-insensitive filesystem, the first thing I did was reinstall the OS.

tom

← back to recent threads