Spróbuj dołączyć "@all" do ścieżki pliku. Na przykład ten wytwarza repo pojedynczej wersji dla mnie:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/...
Polecenie importowane pełną historię:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/[email protected]
Próbowałem za pomocą przykładowy git-P4, ale zrezygnował z kilku powodów i napisał moja własna szybko importowana pompa. Minęło trochę czasu, więc niektóre problemy mogły zostać naprawione teraz, ale git-p4 miał problemy z dużymi listami zmian (np. Początkowe utworzenie gałęzi) (chociaż użycie specyfikacji klienta mogło pomóc, ja nie myślę, że próbowałem) i pliki z modyfikatorem rodzaju pliku "+ S" (który jest Bad And Evil, ale użyliśmy go). A mój Python-fu nie był w stanie pozwolić mi rozwiązać problemów, które miałem.
EDYCJA: ponieważ ktoś o to poprosił, oto jest.
https://github.com/araqnid/p4utils ma kilka rzeczy p4, z których p4-git-xfer jest replikatorem p4-> git (one-way). Ma jednak sporo problemów, ponieważ jest głównie narzędziem osobistym, a nie prawdziwym elementem infrastruktury.
Rozpoczęcie:
p4-git-xfer clone -d $PWD/dictionary.git -n //depot/services/midoffice/dictionary/... \
trunk 'release/*' 'branch/*' \
trunk=master release/*=r* branch/*=dev/*
będzie klonować, że siłą rzeczy ścieżkę do gołego "dictionary.git". Pierwszymi argumentami po ścieżce bazowej są "specyfikacje gałęzi", które wskazują replikatorowi, gdzie znaleźć gałęzie pod bazą. Te późniejsze (z symbolami "=") są "lustrzanymi specyfikacjami", które mówią replikatorowi, jak tworzyć lokalne gałęzie z zaimportowanych. Specyfikacja gałęzi powoduje utworzenie "refs/remote/p4/trunk", "refs/remote/p4/release/1.0" itp. Lustrzane specs wymusza "refs/heads/master", aby odzwierciedlić "refs/remote/p4/trunk", "refs/heads/r1.0", aby odzwierciedlić "refs/remote/p4/release/1.0" itp. To było przeznaczone jako sposób na umożliwienie mi wybrania tylko konkretnych gałęzi z tych, które zostały zreplikowane, aby uzyskać propagację do klonów.
Spróbuje wykryć, jak tworzona jest gałąź, ale w Perforce jest to w pewnym stopniu pewne. Poza tym nie próbuje w ogóle robić żadnego śledzenia gałęzi: nawet scalenia całych gałęzi nie będą zapisywane jako takie, przepraszam.
Po początkowym klonie, uruchomienie p4-git-xfer fetch
z wewnątrz repliki git spowoduje przyrostową aktualizację. Lista zmian o wysokim poziomie wody jest pobierana z marks/p4
w repozytorium git. To jest plik znaczników, który szybko importuje ładunki, więc jeśli masz ochotę na nogą, jak na przykład przy użyciu gałęzi filtra, aby przerobić rzeczy, pamiętaj, że możesz to również zaktualizować.
To nie jest ładne i ma kilka poważnych problemów; Używam go głównie dla własnej wygody, aby odizolować się od problemów z Perforce, a nie jako codziennej krytycznej infrastruktury. Jest jednokierunkowy: generalnie używam skryptu p4-am do stosowania łat stworzonych przez git format-patch
. Że sama tylko działa głównie z ogólnego złośliwość analizowania, problemy z EOF nowej linii, zmiany binarnych itp
Czy Twój skrypt importu p4 jest publiczny? Jeśli tak, czy mógłbyś go udostępnić? – joce