Попробуйте добавить «@all» в путь к файлу. Например, это производит одну ревизию репо для меня:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/...
Эта команда импортировали всю историю:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/[email protected]
Я попытался с помощью примера ГИТ-p4, но отказался по нескольким причинам, и написал мой собственный быстрый импортный насос. Это было некоторое время назад, поэтому некоторые из проблем, возможно, были исправлены сейчас: но git-p4 имел проблемы с большими списками изменений (такими как начальное создание ветки) (хотя использование спецификации клиента могло помочь, я не думаю, я попробовал) и файлы с модификатором типа «+ S» (который является «Плохо и злым», но мы использовали его). И мой Python-fu не мог позволить мне исправить проблемы, которые у меня были.
EDIT: так как кто-то попросил об этом, вот оно.
https://github.com/araqnid/p4utils имеет несколько вещей p4, из которых p4-git-xfer является репликатором p4-> git (односторонний). У этого есть немало проблем, хотя, из-за того, что это в основном личный инструмент, а не реальная часть инфраструктуры.
Начало работы:
p4-git-xfer clone -d $PWD/dictionary.git -n //depot/services/midoffice/dictionary/... \
trunk 'release/*' 'branch/*' \
trunk=master release/*=r* branch/*=dev/*
будет клонировать, что неволей путь к голой "dictionary.git". Первые аргументы после базового пути - это «спецификации ветвей», которые сообщают репликатору, где можно найти ветки под базой. Более поздние (с символами «=») являются «зеркальными спецификациями», которые говорят репликатору, как создавать локальные ветви из импортированных. Спецификации ветки вызывают «refs/remotes/p4/trunk», «refs/remotes/p4/release/1.0» и т. Д., Которые должны быть созданы. Зеркальные спецификации заставляют «refs/heads/master» зеркально отображать «refs/remotes/p4/trunk», «refs/heads/r1.0» для зеркалирования «refs/remotes/p4/release/1.0» и т. Д. как способ позволить мне выбрать только отдельные ветви из тех, которые были реплицированы, чтобы распространить их на клоны.
Он попытается определить, как создается ветка, но это немного похоже на Perforce. Кроме того, он не пытается вообще отслеживать ветки: даже целые ветви не будут выписаны как таковые, извините.
После первоначального клонирования, запущенный p4-git-xfer fetch изнутри git replica будет выполнять инкрементное обновление. Список изменений с водяными знаками берется из marks/p4 в рамках git repo. Это файл меток, который быстро импортирует нагрузки, поэтому, если вы делаете какие-либо причудливые работы, например, используя фильтр-ветвь, переписывайте вещи, будьте осторожны, вам, возможно, придется это обновить.
Это некрасиво и имеет некоторые серьезные проблемы; Я использую его в основном для собственного удобства, чтобы изолировать себя от проблем Perforce, а не как изо дня в день критически важной составляющей инфраструктуры. Это односторонний: я обычно использую скрипт p4-am для применения исправлений, созданных git format-patch. Это само по себе работает только в основном, с общим разборе гадости, проблемы с истекшим файла, переводы строк бинарных изменений и т.д.
Является ли ваш сценарий импорта p4 общедоступным? Если да, не могли бы вы поделиться им? – joce