git mv 并且只更改目录的大小写

git mv and only change case of directory

提问by oschrenk

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

虽然我发现了类似的问题，但我没有找到问题的答案

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

当我尝试通过git mv FOO foo我 将目录从 FOO 重命名为 foo 时

fatal: renaming 'FOO' failed: Invalid argument

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

好的。所以我尝试git mv FOO foo2 && git mv foo2 foo

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

但是当我尝试通过提交时，git commit .我得到

# 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 foonothing changes and git commit .gives me the same message again.

当我通过git add foo没有任何变化添加目录并git commit .再次给我相同的消息时。

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

我究竟做错了什么？我以为我使用的是区分大小写的系统 (OSX)，为什么我不能简单地重命名目录？

回答by Adam Dymitruk

You are in a case insensitive environment. Further, adding with out the -Awill not take care of the remove side of the mvas 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 -ufirst, do this and then git stash popafter. Continuing: To get around this, do the following:

您处于不区分大小写的环境中。此外，添加 out-A将不会处理mvGit 理解的删除方面。警告！确保在执行此操作时没有其他更改或未跟踪的文件，否则它们将作为此更改的一部分提交！git stash -u首先，执行此操作，然后执行此操作git stash pop。继续：要解决此问题，请执行以下操作：

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

这是更改工作目录、提交然后折叠 2 个提交的详细方法。您可以只移动索引中的文件，但是对于 git 的新手来说，它可能不够明确地说明正在发生的事情。较短的版本是

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~5if 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.

正如其中一条评论中所建议的那样，您还可以进行交互式变基（git rebase -i HEAD~5如果在 5 次提交前引入了错误的案例）来修复那里的案例，并且根本不会在历史记录中的任何地方出现错误案例。如果你这样做，你必须小心，因为从那时起提交的哈希值会有所不同，其他人将不得不重新设置或重新合并他们的工作与最近的分支。

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

这与更正文件名有关：git 不区分大小写吗？

回答by mipadi

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

您希望将该选项设置core.ignorecase为 false，这将使 Git 关注本机不支持它的文件系统上的大小写。要在您的回购中启用：

$ git config core.ignorecase false

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

然后你可以重命名文件，git mv它会按预期工作。

回答by mgadda

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

我能够通过使用临时文件名使用 git 1.7.7 解决此问题：

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

回答by wizonesolutions

(git mv-free variant.)

（git mv- 自由变体。）

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

我在 Mac OS X 10.9 上的 Git 中遇到了这个问题。我是这样解决的：

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

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.

这将暂存目录以在 Git 中删除，但实际上并未删除任何物理文件 ( --cached)。这也使目录（现在具有正确的大小写）显示在未跟踪的文件中。

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 statusyou should see a number of renamed:lines. Inspect them and ensure they look correct, and if so, you can commit the changes normally.

然后 Git 会识别出您已经重命名了这些文件，并且当您这样做时，git status您应该会看到许多renamed:行。检查它们并确保它们看起来正确，如果正确，您可以正常提交更改。

回答by Nick Volynkin

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:

如果您首先想先查看结果，请使用-n：

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

After you've made an mv:

在你做了一个之后mv：

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

1. 提交更改
2. 签出到任何其他修订版
3. 结账回来。

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

现在 Git 应该在其内部文件和文件系统中重命名文件夹。

回答by konyak

Force it with -f option:

用 -f 选项强制它：

git mv -f FOO foo

回答by Seeliang

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.

一个名为“Pro”（首先创建）和另一个“pro”（错误创建）的文件夹。在 Mac 中，它是相同的东西，但根据 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.

git config 将文件重命名到正确的文件夹（谢谢），并且还在“pro”中创建了 Ghost 文件（否！！）。我无法向轨道添加幽灵文件更改，除非随身携带这些文件，否则我无法检查其他分支，而且我也无法以某种方式重置它。

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.

对于由创建的ghost文件问题，任何大师都可以解释如何以及为什么？提前致谢。

回答by Nicholas Knight

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

除非您明确选择，否则您不会在 OS X 中使用区分大小写的文件系统。HFS+可以区分大小写，但默认情况下不区分大小写。

回答by Askdesigners

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

这是围绕此页面上所有 gitfoo 的一个非常简单的解决方案。

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.

1. 手动将文件从项目中复制出来。
2. git rm 所有文件。
3. git commit 像往常一样。
4. 手动添加文件。
5. git 添加所有文件。
6. git commit 像往常一样。
7. 利润。

回答by Tony

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

这在 Windows 上对我很有用。使用具有以下功能的 powershell：

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

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. （可选的） git push

Thanks to Adam's answer above.

感谢上面亚当的回答。