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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]