Как сказать Git, что это тот же каталог, просто другое имя

Question

Пройдя несколько препятствий на пути изучения Git, я столкнулся с новой проблемой: переименование каталога (локально, в рабочем каталоге).

Когда я набираю git status, он перечисляет все файлы в старом имени каталога (которые существуют с теми же точными именами файлов в новом каталоге), что и удалено , и новое имя каталога как "не отслежено" .

Есть ли способ сказать Git, что "это фактически тот же каталог, просто другое имя"?

Чтобы все файлы были перечислены git status как измененные только?

Чтобы проиллюстрировать проблему, вот вывод, который я получаю от git status, когда переименовываю весь каталог:

git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    old-dir-name/file1
#   deleted:    old-dir-name/file2
#   deleted:    old-dir-name/file3
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   new-dir-name/
no changes added to commit (use "git add" and/or "git commit -a")
~/sb/ws>

Answer 1

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

Answer 2

Все ответы здесь были очень полезны на пути к фактическому решению для конкретного сценария, с которым я столкнулся. Я предоставляю то, что сработало для меня, в форме реальных шагов, надеюсь, помогая другим, сталкивающимся с той же проблемой:

1. git mv <old-dir-name> <new-dir-name>
2. git status (убедитесь, что все файлы отмечен переименован , а не "удален")
3. git commit -a -m "git mv <old-dir-name> <new-dir-name>" (это «фальшивый» коммит, чтобы подготовить для реального переименования в следующем шаги)
4. git branch git_mv_20110708_1500_DO_NOT_USE ("поддельная" ветка с отметкой времени напоминая, что мы сделали это только как обходной путь)
5. /bin/rm -Rf <new-dir-name>
6. cp -Rp .../<new-dir-name> . (копия поверх фактической папки с переименованное имя)
7. git status (самые измененные файлы теперь будет правильно помечен как изменено , не "удалено". Файлы, которые были переименованы, будут помечены как удаленные и добавлены, несмотря на то же содержание! - повторите шаги 1-7 для этих файлов, если для них тоже требуется отслеживание переименования)
8. git add <untracked files>
9. git commit -a -m "finally renamed this folder"
10. git branch FOLDER_RENAMED:)

P.S. gitk любит это, но Emacs все еще путают с переименованиями. (

Answer 3

Вам нужно использовать git's mv: http://www.kernel.org/pub/software/scm/git/docs/git-mv.html

git mv old_dir new_dir

Поэтому вам нужно переместить новый каталог обратно в старый и перенести его с помощью mv.

РЕДАКТИРОВАТЬ: Чтобы ответить на ответы на мой ответ:

Я решил проверить это сам.Я создал два файла с разным текстом и использовал git mv в одном и mv file file2, git add file2, git add -u в другом.Сообщение фиксации указывало, что оба были отслежены как переименования.Поэтому все, что я советую, это сохранить шаг, как говорили другие.

Answer 4

Git 2.18 (Q2 2018) должен обнаружить, «что это тот же каталог, просто другое имя», потому что «git status» научился обращать внимание на переменные конфигурации diff, связанные с пользовательским интерфейсом, такие как diff.renames.

См. commit dc6b1d9 (04 мая 2018) Экхард С. Маас (``) .
^{(Объединено Junio ​​C Hamano - gitster - в коммит 1e174fd , 23 мая 2018 г.)}

wt-status: используйте настройки от git_diff_ui_config

Если вы делаете что-то вроде:

- git add .
- git status
- git commit
- git show (or git diff HEAD)

можно ожидать аналогичного вывода из git status и git show (или аналогичных программ, связанных с diff).
Обычно это не так, поскольку git status имеет жестко закодированные значения для параметров, связанных с diff.

При этой фиксации жестко заданные настройки удаляются из статуса. команда в пользу значений, предоставленных git_diff_ui_config.

Ниже приведены некоторые замечания о конкретных вариантах, которые были трудными. закодировано в git status:

`diffopt.detect_rename`

С самого начала состояния git в a3e870f («Добавить» commit » helper script ", 2005-05-30, Git v0.99), git status всегда использовал обнаружение переименования, в то время как с такими командами, как show и log, нужно было активировать его с помощью опция командной строки.
После 5404c11 ("diff: активировать diff.renames по default ", 2016-02-25, Git v2.9.0) совпадение по умолчанию ведет себя так же, но изменение diff.renames на другие значения может нарушить согласованность между git status и другие команды снова.
С этим коммитом один управляйте тем же поведением по умолчанию с diff.renames.

`diffopt.rename_limit`

Точно так же есть опция diff.renamelimit, чтобы настроить этот предел для все команды кроме статуса git. С этим коммитом git status также будет чтить те.

---

И то же самое предложение Git 2.18 status.renames, которое может быть полезно для тех, кто хочет это сделать, не отключая обнаружение переименования по умолчанию, выполняемое Команда "git diff".

См. коммит e8b2dc2 (11 мая 2018) Беном Пиартом (benpeart) .
^{(Объединено с Junio ​​C Hamano - gitster - в коммит 5da4847 , 30 мая 2018 г.)}

добавить конфигурацию состояния и параметры командной строки для обнаружения переименования

После выполнения слияния с конфликтами git status по умолчанию попытка обнаружить переименования, что приводит к проверке многих объектов.
В виртуальном репо эти объекты не существуют локально, поэтому логика переименования запускает их выборку с сервера. Это приводит к статусу вызова с этим патчем уходит много часов на очень большие репозитории против секунд.

Добавить новый параметр конфигурации status.renames, чтобы включить отключение переименования обнаружение во время статуса и фиксации.
Этот параметр по умолчанию будет иметь значение diff.renames.

Добавить новую настройку status.renamelimit, чтобы включить ограничение времени потратил на поиск неточных переименований во время статуса и коммита.
Эта настройка по умолчанию будет иметь значение diff.renamelimit.

Добавить --no-renames параметр командной строки к состоянию, который позволяет переопределить Настройка конфигурации из командной строки.
Добавьте к статусу параметр командной строки --find-renames[=<n>], позволяющий обнаруживать переименования и дополнительно устанавливать индекс подобия.

Answer 5

Проблема в пользовательском интерфейсе / пользовательском интерфейсе, а не в «реальной» проблеме для git.Я задал один и тот же вопрос как работать с подкаталогом-переименовывает в git и основной вопрос как сделать-git-запись-или-более-вероятно-представлять-file-paths-and-names-for-the-blob

На самом деле Git это не волнует.Все сообщения, которые вы (мы) получаете, о том, что, по мнению «diff», могло произойти.С другими опциями сообщения будут отличаться, но хранилище не будет отличаться (это тот же снимок!).

Один стиль опции - это опция subtree для diff (хотя она предназначена для другой цели), как и --patience.

Существует необходимость в лучшей опции UI / UXэто будет легче обнаруживать изменения пути (на основе деревьев, а не сгустков).Часть проблемы - тонкая ошибка в аргументе Линуса.Он прав в том, что репозиторий Git должен , а не явно хранить переименование (pathchange), а нам нужна опция, позволяющая правильно его обнаруживать.