git mv и только изменить случай каталога

в то время как я нашел подобное вопрос Я не нашел ответа на мою проблему

когда я пытаюсь переименовать каталог из FOO в foo через git mv FOO foo Я 

fatal: renaming 'FOO' failed: Invalid argument

OK. Поэтому я стараюсь git mv FOO foo2 && git mv foo2 foo

но когда я пытаюсь совершить через 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)

когда я добавляю в каталог через git add foo ничего не меняется и git commit . дает мне то же самое сообщение снова.

что я делаю не так? Я думал, что использую система с учетом регистра (OSX) почему я не могу просто переименовать каталог?

229
case-sensitive git macos version-control

10 ответов

вы находитесь в регистр окружающей среды. Далее, добавив без -A не будет заботиться о удалить стороне mv как это понимает Git. предупреждение! Убедитесь, что при этом нет других изменений или не отслеженных файлов, или они будут зафиксированы как часть этого изменения! 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"

это нарисованный вне путь изменять работу каталог, фиксация, а затем сворачивание 2 коммитов. Вы можете просто переместить файл в индекс, но для кого-то, кто новичок в git, он может быть недостаточно явным относительно того, что происходит. Более короткая версия

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

как было предложено в одном из комментариев, Вы можете также сделать интерактивный перебазирования (git rebase -i HEAD~5 если неправильный случай был введен 5 коммитов назад), чтобы исправить случай там и не иметь неправильный случай появляются в любом месте в истории вообще. Вы должны быть осторожны, если вы делаете это поскольку хэши фиксации с этого момента будут отличаться, и другим придется перебазировать или повторно объединить свою работу с этим недавним прошлым ветви.

это связано с исправлением имени файла:git не чувствителен к регистру?

355

вы хотите установить параметр core.ignorecase в false, что заставит Git обратить внимание на case в файловых системах, которые изначально его не поддерживают. Чтобы включить в вашем РЕПО:

$ git config core.ignorecase false

затем вы можете переименовать файл с git mv и он будет работать, как ожидалось.

129

я смог решить эту проблему, используя git 1.7.7, используя временное имя файла:

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

(git mv-бесплатный вариант.)

я столкнулся с этой проблемой в Git на Mac OS X 10.9. Я решил это следующим образом:

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

это этапы каталога для удаления в Git, но на самом деле не удаляет физические файлы (--cached). Это также делает каталог, теперь с правильным случаем, отображаться в неотслеженных файлах.

так что вы можете сделать это:

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

Git затем распознает, что вы переименовали файлы, и когда вы это сделаете git status вы должны увидеть ряд renamed: строки. Проверьте их и убедитесь, что они выглядят правильно, и если это так, вы можете зафиксировать изменения нормально.

12

принудительно с опцией-f:

git mv -f FOO foo
9

это быстрое и безопасное решение для ошибок:

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

предупреждение! Всегда переименовывайте все файлы в переименованной папке (используйте /*).

не переименовывайте отдельные файлы. Это приводит к ошибке, описанной в этой ответ.

если вы сначала хотите увидеть результат первым, используйте -n:

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

после того, как вы сделали mv:

  1. фиксация изменений
  2. оформить заказ на любой другой ревизия
  3. извлечь обратно.

теперь Git должен был переименовать папку как во внутренних файлах, так и в файловой системе.

7

вы не используете файловую систему с учетом регистра в OS X, если вы явно не выберете такую. На HFS+ can учитывайте регистр, но по умолчанию регистр не учитывается.

2

вот очень простое решение для всех gitfoo на этой странице.

  1. скопируйте файлы из вашего проекта вручную.
  2. git rm все файлы.
  3. git commit как обычно.
  4. добавить файлы вручную.
  5. git добавить все файлы.
  6. git commit как обычно.
  7. прибыль.
1

у меня была одна связанная проблема.

одна папка с именем " Pro "(создана первой) и anther " pro " (создана по ошибке). В Mac это то же самое, но по-разному в соответствии с git.

$ git config core.ignorecase false

конфигурация git переименовывает файлы в правую папку (спасибо), а также создает файлы-призраки в " pro " (нет!!). Я не мог добавить изменения файла призрака в трек, и я не мог проверить другие ветви, если не нести эти файлы со мной, и я также не мог сбросить его как-то.

вместо этого, я сделал 

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

чтобы сделать его более безопасным, я сделал это в ветви функции, а затем я слился обратно в главную ветвь

для Проблемы с файлом-призраком, созданной, может ли любой гуру объяснить, как и почему? Спасибо заранее.

1

улучшение ответа Адама Димитрука (глупо, что так не позволяет мне комментировать его ответ), используя "git mv", автоматически разместит точно перемещенные файлы. Никакого тайника не требуется, и рискованного "git add-A" можно избежать:

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'.";
0