Потерянная история мерзавцев после реорганизации папки проекта

Question

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

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

Answer 1

В Git нет концепции перемещения файлов.

Некоторые инструменты, такие как GitHub, рассматривают коммит, содержащий файл с именем X, который был удален, и файл с именем X, который был создан, перемещают файл.

По словам Линуса Торвальдса, перемещение файлов - это особый случай рефакторинга; по этой причине Git не будет относиться к этому иначе. Обработка этого особого случая, как и многих других, предоставляется инструментам более высокого уровня (например, веб-интерфейсам).

Для получения дополнительной информации по этой теме, проверьте этот ответ от Линуса Торвальдса.

Answer 2

Насколько я вижу, вы хотите:

git log --follow some_file.cpp

Подробнее см. http://git -scm.com / docs / git-log .Я не уверен, что это то, что вы хотите;но в случае с git git отслеживает содержимое, а не файлы.Проблема в том, что определение этой информации действительно дорого, и предполагается, что обычно она вам не нужна ...

Answer 3

Если вы хотите перемещать папки в git, вы можете использовать git mv .

У меня была куча папок в корне моего хранилища, и я хотел переместить их в две подкаталоги, поэтому я создал две новые директории, используя ** mkdir.

Затем я перемещал файлы и папки по одному в новые каталоги, как это:

git mv folder1/ newDirectory1/
git mv file1.txt newDirectory2/

и т.д.

У меня был случай, когда я хотел переименовать один из каталогов в src , и я сделал это так:

git mv folder2 newDirectory1/src

Это привело к набору файлов, которые выглядели так:

repository/
   newDirectory1/
      folder1/
      src/
   newDirectory2/
      file1.txt

После того, как я закончил, я создал новую ветку под названием «реорганизованная», чтобы не мешать работе другого разработчика в основной ветке. Он продолжал работать с файлами, и когда он вносил новые изменения в master, я вытягивал и объединял изменения в свою ветку, и все работало так, как я надеялся. Файлы, которые были перемещены, были должным образом связаны с их исходными местоположениями и получили свои коммиты.

Answer 4

Пробовали ли вы настройки config diff.renames?

diff.renames

Сообщает git обнаруживать переименования.Если задано какое-либо логическое значение, будет включено базовое обнаружение переименования.Если установлено значение «копии» или «копировать», оно также будет обнаруживать копии.

Примечание: для отслеживания истории одного файла при переименовании необходимо использовать «git log -p --follow file».

Answer 5

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

Если это не так, вам может потребоваться посмотреть коммиты с помощью git log -M -C

Answer 6

Я бы запустил скрипт, который проходит через все объекты. Вам нужно будет сначала распаковать все файлы пакета. Скрипт проверит тип, если это коммит, вы увидите, если вы автор. Тогда проверьте дату. Перечислите те и grep для имени файла, который вы хотите. Получив коммит, создайте ветку с

git branch RecoveredWork hash-of-your-commit

и посмотрите, есть ли у вас все, что вы хотите с

git log RecoveredWork --graph --decorate

отсюда вы можете захотеть сделать несколько разветвлений фильтра, прививки и / или перебазировки, чтобы снова связать историю.

Answer 7

Если вы на самом деле пропускаете ревизии из своей истории (из вашего вопроса не совсем ясно, чего на самом деле не хватает) и прошло всего около месяца, у вас, вероятно, еще есть время - посмотрите на reflog; он хранит копию каждой ссылки, которую вы извлекли, поэтому, если вы допустите ошибку, вы сможете вернуть то, что у вас было раньше.

По умолчанию записи рефлогов сохраняются в течение 90 дней, срок действия которых истекает git gc.

git help reflog