How to correctly change filename case in Git on OSX

Question

On OSX 10.10.2 and Git 2.2.1 with this filesystem: File System Personality: Journaled HFS+ Type (Bundle): hfs Name (User Visible): Mac OS Extended (Journaled)

I've seen several questions and answers related to this: Unresolvable Git error: The following untracked working tree files would be overwritten by checkout

The actual solution that worked in that question is not clearly specified but involves:

It took me some file history breakup (deleting and re-adding files) to resolve this error after setting the option to true.

I've tried the other solutions presented, but I am still left with the problem of how to move the file correctly.

Having run:

sudo git config --unset-all core.ignorecase && sudo git config --system core.ignorecase false

I then still cannot rename the files using (git 2.2.1) because I get a fatal: destination exists error:

git mv File.name file.name

I can rename them using:

git mv File.name File.name.tmp
git mv File.name.tmp file.name

However I am then unable to checkout an older commit/branch because I get this message:

error: The following untracked working tree files would be overwritten by merge:
File.name

If I force the checkout or change ignorecase to true, I can switch branches, but then I can't still can't merge in the changes because I get this message:

error: The following untracked working tree files would be overwritten by merge:
file.name

Note that the conflicting file name changes its case in those two error messages. Running a git reset --hard HEAD doesn't resolve the issue in either of these cases.

Is this a bug in git? Am I doing it wrong? I don't see anyway to force that merge, what else can I do? Do have have to remove and re-add the file, thus breaking the history of changes to that file?

Edit: So far it seems like the only solution (that preserves file history and doesn't require breaking older releases by rewriting project history) is to split the renaming up into two commits and then require anyone that merges this branch to manually merge twice.

can you do something like move, make an actual commit, then move back, make an actual commit? git tries to combine all the diffs in one singe commit so if you rm and add in a different place, git will just see it as a move... — Grady Player, Jan 14 '16 at 20:55
@GradyPlayer spliting the two moves into two commits does not solve the problem. I still get the untracked working tree files error. — Omn, Jan 14 '16 at 21:12
@GradyPlayer I can merge the first commit, and then merge the second commit, but this is also pretty suboptimal. I'm worried that if I Push this code to the origin, people trying to Pull from origin will have to manually do two merges from origin to get their local branch up to speed. We may not lose file history, but this introduces a weird arcane issue to the repository. — Omn, Jan 14 '16 at 21:21
I have dealt with this general problem of working on a case-sensitive project on OS X by making a case-sensitive disk image in Disk Utility and working on the project there. It's a stop gap to remove filesystem case-sensitivity from the project. — Schwern, Jan 14 '16 at 21:49
@Schwern but doesn't that mean that every developer that tries to create a working copy will be unable to merge this branch unless they also make a case-sensitive disk image? — Omn, Jan 14 '16 at 21:59
@Omn Yes. So you use that case-sensitive image to eliminate the case-sensitive bits from the project. A lot of rebasing and git-filter-branch. — Schwern, Jan 14 '16 at 22:13
@Schwern I'm not sure what your point is. I can change the case in the repository either from OSX's case-insensitive filesystem, or from our Ubuntu server's case-sensitive filesystem. Either way this creates the same problems during merging for people using OSX's case-insensitive filesystem. If I rewrite the whole project so that the file has always had the new case, then that breaks the case-sensitive functionality of all the old branches and releases. — Omn, Jan 15 '16 at 01:09
@Omn If the project relies on case-sensitivity you can work around the case issues, but everyone on a case-insensitive filesystem (OS X & Windows primarily) will have the same problems, and they will keep happening. Ultimately that the project relies on case-sensitivity is the problem. If you want to make the project work for OS X in general, eliminate case-sensitivity entirely. This might cause problems with existing branches, you'll have to work through them like changing any other assumption about the environment. I can't say more without details of the project. — Schwern, Jan 15 '16 at 05:15
@Schwern The project doesn't rely on case-sensitivity in that nothing is ambiguous without case, but the project does need to be compatible with the case sensitive file systems common on linux VPS's. Obviously this means that there is a downside to doing development on a case-insensitive file system because some problems won't become apparent until tested on a case-sensitive server. — Omn, Jan 15 '16 at 19:25
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/100806/discussion-between-schwern-and-omn). — Schwern, Jan 15 '16 at 20:18

entpnerd · Answer 1 · 2016-01-15T01:51:53.563

I use Mac OSX, and for most of my Git work, I use Atlassian's SourceTree. I just tried renaming a file on there by right clicking the unstaged file I want to rename, selecting the Move option, and just renaming the file and leaving it in its present location. It worked for me. I hope that helps. Comment with any follow up questions.

Edit: Adding results of diskutil info / as per comment request: BELC02NF206G3QN:~ jthoms$ diskutil info / Device Identifier: disk1 Device Node: /dev/disk1 Part of Whole: disk1 Device / Media Name: Macintosh HD

Volume Name:              Macintosh HD

Mounted:                  Yes
Mount Point:              /

File System Personality:  Journaled HFS+
Type (Bundle):            hfs
Name (User Visible):      Mac OS Extended (Journaled)
Journal:                  Journal size 24576 KB at offset 0x19502000
Owners:                   Enabled

Content (IOContent):      Apple_HFS
OS Can Be Installed:      Yes
Recovery Disk:            disk0s3
Media Type:               Generic
Protocol:                 PCI
SMART Status:             Not Supported
Volume UUID:              D2FB2CB7-9CA8-38D1-9116-AA88AFC39748
Disk / Partition UUID:    01D2D5C8-8300-4FE6-9ED5-07C5D4C0879D

Total Size:               249.8 GB (249795969024 Bytes) (exactly 487882752 512-Byte-Units)
Volume Free Space:        27.0 GB (27011723264 Bytes) (exactly 52757272 512-Byte-Units)
Device Block Size:        512 Bytes
Allocation Block Size:    4096 Bytes

Read-Only Media:          No
Read-Only Volume:         No
Ejectable:                No

Whole:                    Yes
Internal:                 Yes
Solid State:              Yes
OS 9 Drivers:             No
Low Level Format:         Not supported

This disk is a Core Storage Logical Volume (LV).  Core Storage Information:
LV UUID:                  01D2D5C8-8300-4FE6-9ED5-07C5D4C0879D
LVF UUID:                 AC10903C-43BB-403E-BD90-F7BF785DF8AC
LVG UUID:                 B0718DFB-82C0-402C-836E-DD3B32E5EEDC
Fusion Drive:             No
Encrypted:                Yes

I don't think you understand the problem, which is renaming a file that only involves change the case of the filename. Using SourceTree's 'Move' functionality produces the error "fatal: destination exists"... that also occurs when trying to rename the file using "git mv File.name file.name" — Omn, Jan 14 '16 at 21:57
Oh bizarre. For me, I renamed *PricingExecutor.java* to *pricingexecutor.java* in the same directory and it worked fine - commit, `ls` and all. I used SourceTree's *Move* option like I said and it worked. I wonder if there is a non-Git issue going on. Are you able to rename your files to use different cases on the command line via the *mv* command or something similar? — entpnerd, Jan 14 '16 at 22:28
Yes, I can rename files in using mv since OSX is 'case preserving' but not 'case sensitive'. The problem appears to be with how Git tracks the working directory getting confused by the move and thinking there is a untracked file when there is not. — Omn, Jan 15 '16 at 01:04
I am curious as to why you do not have this issue. What are your OSX and Git versions and what does `diskutil info /` output for your 'File System Personality' and 'Name (User Visible)' — Omn, Jan 15 '16 at 01:46
huh, I wonder if this is a bug that is fixed in your version of git. Thanks — Omn, Jan 15 '16 at 02:15

How to correctly change filename case in Git on OSX

1 Answers1