Can't handle renamed resources on case insensitive filesystems.

Can't handle renamed resources on case insensitive filesystems.

[Lhunath (Maarten B.)]

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.

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

[Erik Faye-Lund]

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.


-- 
Erik "kusma" Faye-Lund

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

[Tomas Carnecky]

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

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

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

[Erik Faye-Lund]

On Mon, Dec 14, 2009 at 3:50 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> 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