#git #git-merge-conflict #consolidation #git-history #git-mv
Вопрос:
У меня есть следующий сценарий:
основная ветвь до консолидации:
│ └── dir1
│ │ └── python1
│ │ │ └── test1.py
│ └── dir2
│ │ └── python2
│ │ │ └── test2.py
│ └── dir3
│ │ └── python3
│ │ │ └── test3.py
основная ветвь после консолидации:
│ └── dir1
│ └── dir2
│ │ └── python1
│ │ │ └── test1.py
│ │ └── python2
│ │ │ └── test2.py
│ │ └── python3
│ │ │ └── test3.py
│ └── dir3
ветвь функции перед слиянием ( test4.py в истории есть 10 фиксаций в истории):
│ └── dir1
│ │ └── python1
│ │ │ └── test4.py
основная ветвь после слияния из ветви функций (использование git merge -s ort и разрешение конфликта на несуществующей test4.py ):
│ └── dir1
│ └── dir2
│ │ └── python1
│ │ │ └── test1.py
│ │ │ └── test4.py
│ │ └── python2
│ │ │ └── test2.py
│ │ └── python3
│ │ │ └── test3.py
│ └── dir3
Проблема в том, что вся история test4.py была удалена… есть идеи, почему это происходит и можно ли этого избежать?
Комментарии:
1. Небольшая особенность дизайна git заключается в том, что он на самом деле не отслеживает копии или переименования каким-либо постоянным способом. Вместо этого различные команды истории имеют возможность восстанавливать переименования при сравнении фиксаций. Таким образом, имеет значение, какую команду вы используете, чтобы попытаться просмотреть историю test4.py
2.
git blame/gitk/git log, а также пытался использовать графический интерфейс intelji, но ничего не показывает историю3. Об этом можно подумать следующим образом: у Git нет истории файлов. У Git есть коммиты, и коммиты-это история.
git logпоказывает фиксации, найденные по тому факту, что они являются историей;git log -- pathвыбирает подмножество истории фиксаций для обхода, а затем показывает еще меньшее подмножество этого подмножества;git log --follow -- pathпытается обнаружить переименования файлов и изменяет способgit log -- pathработы, изменяя путь, который он использует для выбора подмножества, по ходу.4. Все это довольно хорошо работает в большинстве случаев, но в сложных случаях переименования и переделки это может довольно сильно не сработать. Похоже, у вас один из таких случаев.
5. В будущем старайтесь избегать перемещения/переименования файла и изменения его в одной и той же фиксации. Если вы можете сделать одно, а не другое, git почти гарантированно сможет отслеживать историю файла по переименованиям и перемещениям.
Ответ №1:
Если слияние удалено dir1/python1/test4.py из вашего целевого дерева, то объединенная ветвь удалила этот файл. Но теперь я вижу, что он просто передвинул его. Если вы хотите просмотреть историю этого файла,
gitk --follow -- dir2/python1/test4.py
покажет его вам, если он также не изменился до неузнаваемости. Вы можете попробовать добавить -M50 , если это очень существенно изменилось, и --full-history проверить происхождение, которое не оказало никакого влияния на основную линию, на случай, если вы хотите увидеть изменения, которые были отменены или иным образом оказались идентичными изменениям, которые Git уже показывает вам..
git blame всегда выполняется --follow (это так часто то, что требуется, никто еще не учил его ничему, чтобы этого не делать), но вам нужно выследить коммит, в котором он есть.
Если файл был не просто перемещен, а фактически удален, если он сейчас не существует, git log -1 --pretty=%h -- path/to/that/test4.py найдите фиксацию, которая его удалила, поставьте галочку ^ в конце вывода, и это последняя фиксация перед удалением.
Комментарии:
1. Таким образом, это означает, что нет никакого способа получить историю файлов для
dir2/python1/test4.py?2. Я неправильно истолковал ваш вопрос, я остановился на «несуществующем test4.py» и не видел, чтобы он был спрятан там под dir2. Если слияние также не изменило его до неузнаваемости
gitk --follow -- dir2/python1/test4.pyи так далее, все будет в порядке.3. Я уточнил вопрос. в любом случае это не работает, я не вижу истории использования этой команды на
dir2/python1/test4.py4. Если он был перемещен и существенно изменен , вам, возможно, придется расширить поиск с помощью чего-то вроде
-M50, см.git logДокументы,gitkпринимает все аргументы выбора журнала.5. Ну,я провожу командное тестирование истории git с помощью git-legacy-stash.sh и это работает идеально, так что в вашей истории есть что-то особенное, что запускает механизм отслеживания переименований. Является ли это публичным репо?