git mv and only change case of directory

Question

While I found similar question I didn't find an answer to my problem

When I try to rename the directory from FOO to foo via git mv FOO foo I get

fatal: renaming 'FOO' failed: Invalid argument

OK. So I try git mv FOO foo2 && git mv foo2 foo

But when I try to commit via git commit . I get

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# foo
nothing added to commit but untracked files present (use "git add" to track)

When I add the directory via git add foo nothing changes and git commit . gives me the same message again.

What am I doing wrong? I thought I'm using a case-sensitive system (OSX) why can't I simply rename the directory?

Answer 1

You are in a case insensitive environment. Further, adding with out the -A will not take care of the remove side of the mv as Git understands it. Warning! Ensure that no other changes or untracked files are around when you do this or they will get committed as part of this change! git stash -u first, do this and then git stash pop after. Continuing: To get around this, do the following:

mv foo foo2
git add -A
git commit -m "renaming"
mv foo2 FOO
git add -A
git commit --amend -m "renamed foo to FOO"

That's the drawn out way of changing the working directory, committing and then collapsing the 2 commits. You can just move the file in the index, but to someone that is new to git, it may not be explicit enough as to what is happening. The shorter version is

git mv foo foo2
git mv foo2 FOO
git commit -m "changed case of dir"

As suggested in one of the comments, you can also do an interactive rebase (git rebase -i HEAD~5 if the wrong case was introduced 5 commits ago) to fix the case there and not have the wrong case appear anywhere in the history at all. You have to be careful if you do this as the commit hashes from then on will be different and others will have to rebase or re-merge their work with that recent past of the branch.

This is related to correcting the name of a file: Is git not case sensitive?

Answer 2

You want to set the option core.ignorecase to false, which will make Git pay attention to case on file systems that don't natively support it. To enable in your repo:

$ git config core.ignorecase false

Then you can rename the file with git mv and it'll work as expected.

Answer 3

I was able to resolve this, using git 1.7.7 by using a temporary filename:

$ git mv improper_Case improve_case2
$ git mv improve_case2 improve_case
$ git commit -m "<your message>"

Answer 4

(git mv-free variant.)

I ran into this problem in Git on Mac OS X 10.9. I solved it as follows:

git rm -r --cached /path/to/directory

That stages the directory for deletion in Git but does not actually remove any physical files (--cached). This also makes the directory, now with the proper case, show up in untracked files.

So you can do this:

mv /path/to/directory /path/to/DIRECTORY
git add -A /path/to/DIRECTORY

Git will then recognize that you have renamed the files, and when you do git status you should see a number of renamed: lines. Inspect them and ensure they look correct, and if so, you can commit the changes normally.

Answer 5

This is a quick and bug-safe solution:

git mv -f path/to/foo/* path/to/FOO/

Warning! Always rename all files in the renamed folder (use /*).

Do not rename single files. This leads to a bug, described in this answer.

If you first want to see the outcome first, use -n:

git mv -f -n path/to/foo/* path/to/FOO/

After you've made an mv:

1. Commit changes
2. Checkout to any other revision
3. Checkout back.

Now Git should have renamed the folder BOTH in its internal files and in file system.

Answer 6

Force it with -f option:

git mv -f FOO foo

Answer 7

I had one related issue.

One folder named 'Pro' (created first) and another 'pro' (created by mistake). In Mac, it is the same thing, but different according to git.

$ git config core.ignorecase false

the git config rename the files to the right folder(thanks), and also created ghost files in 'pro' (No!!). I could not add ghost file changes to the track and I could not checkout other branches unless carry those those files with me, and i also could not reset it somehow.

Instead of that, i did

$ git rm -r --cached pro
$ git status // => pro files removed, new Pro files untracked
$ git add Pro

To make it extra safe, i did it in a separated fix branch, and then i merged back to main branch

For the ghost file issue created by , can any guru explain How and Why? Thanks in advance.

Answer 8

You're not using a case-sensitive filesystem in OS X unless you explicitly choose such. HFS+ can be case-sensitive, but the default is case-insensitive.

Answer 9

This worked great for me on Windows. Used powershell with the following:

1. mv .\Folder-With-Wrong-Casing .\temp
2. git add -A
3. git commit -m "renamed folder with wrong casing to temp"
4. mv .\temp .\Folder-with-Correct-Casing
5. git add -A
6. git commit --amend -m "Renamed to proper casing"
7. (optional) git push

Thanks to Adam's answer above.

Answer 10

Here's a really simple solution around all the gitfoo on this page.

1. Copy the files out of your project manually.
2. git rm all the files.
3. git commit like normal.
4. add the files back manually.
5. git add all the files.
6. git commit like normal.
7. profit.

Answer 11

Improving Adam Dymitruk's answer (silly that SO doesn't let me comment his answer), using "git mv" will automatically stage exactly the moved files. No stashing is needed and the risky "git add -A" can be avoided:

old="abc";    new="ABC";
tmp="$old-renamed";
git mv "$old" "$tmp";
git commit -m "Renamed '$old' to '$tmp'.";
git mv "$tmp" "$new";
git commit --amend -m "Renamed '$old' to '$new'.";