Re: Can't handle renamed resources on case insensitive filesystems.
- From
Tomas Carnecky <tom@dbservice.com>
- Date
- Dec 14, 2009, 14:52 UTC
- Message-ID
- <4B26511F.5040804@dbservice.com>
- In-Reply-To
- <63135FDB-C8EF-4DBC-AEF5-4B0636C8D349@gmail.com>
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