Попробуйте добавить "@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/...@all
Я попытался использовать пример git-p4, но сдался по нескольким причинам и написал свой собственный быстрый импортный насос. Это было некоторое время назад, поэтому некоторые проблемы могли быть решены сейчас: но у git-p4 были проблемы с большими списками изменений (такими как первоначальное создание ветви) (хотя использование спецификации клиента могло помочь, я не Кажется, я попробовал это) и файлы с модификатором типа файла "+ S" (это Bad And Evil, но мы использовали его). И мой Python-fu не позволил мне решить проблемы, которые у меня были.
РЕДАКТИРОВАТЬ: так как кто-то просил об этом, вот оно.
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 /глав / мастер» отражать «refs / remotes / p4 / trunk», «refs / head / r1.0» отражать «refs / remotes / p4 / release / 1.0» и т.д. как способ позволить мне выбирать только определенные ветви из тех, которые были реплицированы для распространения в клонах.
Он попытается определить, как создается ветвь, но в любом случае с Perforce это немного догадка. Кроме того, он вообще не пытается отслеживать ветки: даже слияния целых ветвей не будут записываться как таковые, извините.
После первоначального клона запуск p4-git-xfer fetch из реплики git будет выполнять постепенное обновление. Список изменений верхнего уровня взят из marks/p4 в репозитории git. Это файл меток, который загружает при быстром импорте, поэтому, если вы делаете какую-то сложную работу, такую как использование filter-branch для перезаписи, будьте осторожны, возможно, вам придется обновить это тоже.
Это не красиво, и есть некоторые проблемы от среднего до серьезного; Я использую его в основном для собственного удобства, чтобы изолировать себя от проблем Perforce, а не как повседневный критический компонент инфраструктуры. Это односторонний подход: я обычно использую скрипт p4-am для применения патчей, созданных git format-patch. Это само по себе работает только в основном, с общим разбросом разбора, проблемами с символами новой строки в конце файла, двоичными изменениями и т. Д.