Essayez d'ajouter "@all" au chemin du fichier. Par exemple, cela produit une prise en pension unique révision pour moi:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/...
Cette commande a importé l'historique complet:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/[email protected]
J'ai essayé d'utiliser l'exemple git-p4, mais a abandonné pour plusieurs raisons et écrit ma propre pompe à importation rapide. Il y a un certain temps, certains problèmes ont peut-être été corrigés: mais git-p4 avait des problèmes avec les grandes changelists (comme la création initiale d'une branche) (bien que l'utilisation de la spécification client ait aidé, je ne pense que je l'ai essayé) et les fichiers avec le modificateur de type de fichier "+ S" (qui est Bad And Evil, mais nous avions l'habitude de l'utiliser). Et mon Python-fu n'était pas prêt à me laisser réparer les problèmes que j'avais.
EDIT: depuis que quelqu'un l'a demandé, le voici.
https://github.com/araqnid/p4utils a plusieurs choses p4, dont p4-git-xfer est le réplicateur p4-> git (unidirectionnel). Il a cependant quelques problèmes, car il s'agit principalement d'un outil personnel et pratique plutôt que d'une véritable infrastructure.
Mise en route:
p4-git-xfer clone -d $PWD/dictionary.git -n //depot/services/midoffice/dictionary/... \
trunk 'release/*' 'branch/*' \
trunk=master release/*=r* branch/*=dev/*
clonerons ce chemin Perforce à nu "dictionary.git". Les premiers arguments après le chemin de base sont des "spécifications de branche" qui indiquent au réplicateur où trouver les branches sous la base. Les derniers (avec les symboles '=') sont des "spécifications de miroir" qui indiquent au réplicateur comment créer des branches locales à partir des importées. Les spécifications de branche provoquent la création de "refs/remotes/p4/trunk", "refs/distants/p4/release/1.0" etc. Les spécifications du miroir forcent "refs/heads/master" à refléter "refs/remotes/p4/trunk", "refs/heads/r1.0" pour refléter "refs/remotes/p4/release/1.0", etc. comme un moyen de me permettre de sélectionner seulement des branches particulières de celles qui ont été répliquées pour se propager aux clones.
Il essayera de détecter comment une branche est créée, mais c'est un peu une supposition de toute façon avec Perforce. En dehors de cela, il n'essaie pas de faire du tout de suivi de branche: même les fusions de branches entières ne seront pas écrites en tant que telles, désolé.
Après le clonage initial, l'exécution de p4-git-xfer fetch depuis l'intérieur de la réplique git effectuera une mise à jour incrémentielle. La liste des modifications de marque haute est prise de marks/p4 dans le repo git. Il s'agit d'un fichier de marquage qui permet d'importer rapidement des données, donc si vous utilisez une branche de filtre pour réécrire des éléments, prenez garde, vous devrez peut-être également mettre à jour ceci.
Ce n'est pas joli, et a quelques problèmes moyens à sérieux; Je l'utilise principalement pour ma propre commodité, pour m'isoler des problèmes de Perforce, et non comme un composant critique de l'infrastructure au jour le jour. C'est unidirectionnel: j'utilise généralement le script p4-am pour appliquer les correctifs créés par git format-patch. Qui se ne fonctionne que pour la plupart, avec des malédictions d'analyse générale, les problèmes avec les nouvelles lignes de fin de fichier, les modifications binaires etc.
Votre script d'importation p4 est-il public? Si oui, cela vous dérangerait-il de le partager? – joce