Ställ in miljövariabeln GIT_DIR. Se git[1].

Tillhandahåll mer framstegs-information.

Importera ändringar till <ref> istället för refs/remotes/p4/master. Om <ref> börjar med refs/, används det som det är. Annars, om det inte börjar med p4/, läggs det prefixet till.

    $ git init
    $ git p4 sync --branch=refs/remotes/p4/proj2 //deplå/proj2

Använd grendetekterings-algoritmen för att hitta nya sökvägar i p4. Det dokumenteras nedan i "GREN-DETEKTERING".

Importera exakt de p4-ändringsnummer som anges i fil, ett per rad. Normalt sett inspekterar git p4 det aktuella p4-förvaret och identifierar de ändringar som ska importeras.

Skriv inte ut någon förloppsinformation.

Fråga p4 efter etiketter associerade med depåsökvägarna och lägg till dem som taggar i Git. Begränsad användbarhet eftersom endast importerar etiketter associerade med nya ändringslistor. Föråldrad.

Importera etiketter från p4 till Git.

Som standard, lagras p4-grenar i refs/remotes/p4/, där de kommer att behandlas som fjärrspårningsgrenar av git-branch[1] och andra kommandon. Det här alternativet placerar istället p4-grenar i refs/heads/p4/. Observera att framtida synkroniseringsåtgärder också måste ange --import-local så att de kan hitta p4-grenarna i refs/heads.

Importera högst n ändringar, snarare än hela intervallet av ändringar som ingår i den givna revisionsspecifikationen. En typisk användning skulle vara att använda @all som revisionsspecifikation, men sedan använda --max-changes 1000 för att importera endast de senaste 1000 revisionerna snarare än hela revisionshistoriken.

Den interna blockstorleken som ska användas vid konvertering av en revisionsspecifikation, till exempel @all, till en lista med specifika ändringsnummer. Istället för att använda ett enda anrop till p4 changes för att hitta hela listan över ändringar för konverteringen, finns det en sekvens av anrop till p4 changes -m, som vart och ett begär ett block med ändringar av den angivna storleken. Standardblockstorleken är 500, vilket vanligtvis borde vara lämpligt.

Mappningen av filnamn från p4-depåns sökväg till Git innebär som standard att hela depåns sökväg tas bort. Med det här alternativet behålls hela p4-depåns sökväg i Git. Till exempel blir sökvägen //depot/main/foo/bar.c, när den importeras från //depot/main/, foo/bar.c. Med --keep-path är Git-sökvägen istället depot/main/foo/bar.c.

Använd en klientspecifikation för att hitta listan över intressanta filer i p4. Se avsnittet "KLIENT-SPECIFIKATION" nedan.

Exkludera valda depåsökvägar vid kloning eller synkronisering.

Var Git-förvaret ska skapas. Om inget anges används den sista komponenten i p4-depåns sökväg för att skapa en ny katalog.

Utför en bar kloning. Se git-clone[1].

Uppströms plats från vilken incheckningar identifieras för att skickas till p4. Som standard är detta den senaste p4-incheckning som kan nås från HEAD.

Identifiera namnbyten. Se git-diff[1]. Namnbyten kommer att representeras i p4 med hjälp av explicita flytta-operationer. Det finns inget motsvarande alternativ för att upptäcka kopior, men det finns variabler för både flyttningar och kopior.

Om-författa p4-ändringar innan du skickar till p4. Det här alternativet kräver administratörs-behörighet för p4.

Exportera taggar från Git som p4-etiketter. Taggar som finns i Git tillämpas på perforce-arbetskatalogen.

Visa exakt vilka incheckningar som skulle skickas till p4; ändra inte tillstånd i Git eller p4.

Tillämpa en incheckning på p4-arbetsytan, öppna, lägg till och ta bort filer i p4 som för en vanlig sändningsoperation (submit). Utfärda inte den sista "p4 submit", utan skriv istället ut ett meddelande om hur man skickar manuellt eller återställer. Det här alternativet stannar alltid efter den första (äldsta) incheckningen. Git-taggar exporteras inte till p4.

Istället för att skicka in, skapa en serie lagrade ändringslistor. Efter att varje lagrad fil skapats återställs/tas de relevanta filerna bort. Om du har flera väntande incheckningar kommer flera lagrade filer att skapas.

Uppdatera en befintlig ändringslista från hyllan med denna incheckning. Innebär --shelve. Upprepa för flera ändringslistor från hyllan.

Konflikter kan uppstå när man tillämpar en incheckning på p4. När detta händer är standardbeteendet ("fråga") att fråga om man ska hoppa över denna incheckning och fortsätta, eller avsluta. Det här alternativet kan användas för att kringgå frågan, vilket gör att motstridiga incheckningar hoppas över automatiskt, eller för att avsluta försöken att tillämpa incheckningar utan att fråga.

Efter inskicka, synkronisera den här namngivna grenen istället för standard p4/master. Se avsnittet "Synkroniseringsalternativ" ovan för mer information.

Skicka endast in den angivna incheckningen eller intervallet av incheckningar, istället för den fullständiga listan över ändringar som finns i den aktuella Git-grenen.

Inaktivera den automatiska ombasringen efter att alla incheckningar har skickats in. Kan också ställas in med git-p4.disableRebase.

Inaktivera automatisk synkronisering av p4/master från Perforce efter att incheckningar har skickats. Innebär --disable-rebase. Kan också ställas in med git-p4.disableP4Sync. Synkroniseringen med origin/master fortsätter fortfarande om möjligt.

Importera p4-etiketter.

Ställer in git refspec:n mot vilken den lagrade P4-ändringslistan jämförs. Standardinställningen är p4/master.

Användare specificerad som ett alternativ för alla p4-kommandon, med -u <användare>. Miljövariabeln P4USER kan användas istället.

Lösenord anges som ett alternativ för alla p4-kommandon, med -P <lösenord>. Miljövariabeln P4PASS kan användas istället.

Port anges som ett alternativ för alla p4-kommandon, med -p <port>. Miljövariabeln P4PORT kan användas istället.

Värd anges som ett alternativ för alla p4-kommandon, med -h <värd>. Miljövariabeln P4HOST kan användas istället.

Klient specificerad som ett alternativ för alla p4-kommandon, med -c <klient>, inklusive klientspecifikationen.

Anger hur många gånger ett p4-kommando (särskilt p4 sync) ska försökas igen om nätverket får timeout. Standardvärdet är 3. Ställ in värdet till 0 för att inaktivera återförsök eller om din p4-version inte stöder återförsök (före 2012.2).

Eftersom det går mycket snabbare att importera incheckningar från andra Git-förvar än att importera dem från p4, finns det en mekanism för att hitta p4-ändringar först i Git fjärrar. Om det finns grenar under refs/remote/origin/p4 kommer dessa att hämtas och användas vid synkronisering från p4. Denna variabel kan sättas till false för att inaktivera detta beteende.

En fas i grendetektering innebär att man tittar på p4-grenar för att hitta nya att importera. Som standard inspekteras alla grenar. Det här alternativet begränsar sökningen till endast de som ägs av den enskilda användare som namnges i variabeln.

Lista över grenar som ska importeras när grenidentifiering är aktiverad. Varje post ska vara ett par grennamn separerade med ett kolon (:). Detta exempel deklarerar att både grenA och grenB skapades från main:

git config       git-p4.branchList main:grenA
git config --add git-p4.branchList main:grenB

Lista över p4-etiketter att ignorera. Denna skapas automatiskt när etiketter som inte kan importeras upptäcks.

Importera p4-etiketter till git, enligt --import-labels.

Endast p4-etiketter som matchar detta reguljära uttryck kommer att importeras. Standardvärdet är [a-zA-Z0-9_\-.]+$.

Ange att p4-klientspecifikationen ska användas för att identifiera intressanta p4-depåsökvägar. Detta motsvarar att ange alternativet --use-client-spec. Se avsnittet "KLIENTSPEC" ovan. Denna variabel är en booleskt värde, inte namnet på en p4-klient.

Perforce behåller kodningen av en sökväg som den ges av det ursprungliga operativsystemet. Git förväntar sig sökvägar kodade som UTF-8. Använd den här konfigurationen för att tala om för git-p4 vilken kodning Perforce använde för sökvägarna. Denna kodning används för att omkoda sökvägarna till UTF-8. Som ett exempel använder Perforce i Windows ofta "cp1252" för att koda sökvägsnamn. Om det här alternativet skickas till en p4-klonförfrågan, sparas det i det resulterande nya git-förvaret.

Perforce behåller kodningen av ändringslistbeskrivningar och användarnamn som lagras av klienten på ett givet operativsystem. p4v-klienten använder den lokala operativsystemkodningen, och därför kan olika användare lagra olika ändringslistbeskrivningar eller användarnamn i olika kodningar, i samma depå. Git tolererar inkonsekventa/felaktiga kodningar i inchecknings-meddelanden och författarnamn, men förväntar sig att de anges i utf-8. git-p4 kan använda tre olika avkodningsstrategier för att hantera kodningsosäkerheten i Perforce: passthrough skickar helt enkelt de ursprungliga bytena från Perforce till git, vilket skapar användbar men felaktigt kodad data när Perforce-datan är kodad som något annat än utf-8. strict förväntar sig att Perforce-datan ska kodas som utf-8 och misslyckas med att importera när detta inte är sant. fallback försöker tolka data som utf-8 och återgår annars till att använda en sekundär kodning - som standard den vanliga Windows-kodningen cp-1252 - med byte i övre intervallet escaped om avkodning med fallback-kodningen också misslyckas. Under python2 är standardstrategin "passthrough" av historiska skäl, och under python3 är standarden "fallback". När "strict" är valt och avkodningen misslyckas, kommer felmeddelandet att föreslå att denna konfigurationsparameter ändras som en lösning. Om detta alternativ skickas till en p4-klonförfrågan, sparas det i det resulterande nya git-repot.

Ange den reservkodning som ska användas vid avkodning av Perforce-författarnamn och beskrivningar av ändringslistor med hjälp av strategin fallback (se git-p4.metadataDecodingStrategy). Reservkodningen kommer endast att användas vid avkodning då utf-8 misslyckas. Standardinställningen är cp1252, en vanlig Windows-kodning. Om den här inställningen skickas till en p4-klonförfrågan sparas den i det resulterande nya git-förvaret.

Ange det system som används för stora (binära) filer. Observera att stora filsystem inte stöder kommandot git p4 submit. Endast Git LFS är implementerat just nu (se https://git-lfs.github.com/ för mer information). Ladda ner och installera kommandoradstillägget Git LFS för att använda det här alternativet och konfigurera det så här:

git config       git-p4.largeFileSystem GitLFS

Alla filer som matchar en filändelse i listan kommer att bearbetas av det stora filsystemet. Använd inte prefixet . för filändelserna.

Alla filer med en okomprimerad storlek som överstiger tröskelvärdet kommer att bearbetas av det stora filsystemet. Som standard definieras tröskelvärdet i byte. Lägg till suffixet k, m eller g för att ändra enheten.

Alla filer med en komprimerad storlek som överstiger tröskelvärdet kommer att bearbetas av det stora filsystemet. Det här alternativet kan göra klonings-/synkroniseringsprocessen långsammare. Som standard definieras tröskelvärdet i byte. Lägg till suffixet k, m eller g för att ändra enheten.

Boolesk variabel som definierar om stora filer automatiskt skickas till en server.

En ändringslista som endast innehåller exkluderade filer kommer att importeras som en tom incheckning om det här booleska alternativet är satt till sant.

Mappa en P4-användare till ett namn och en e-postadress i Git. Använd en sträng med följande format för att skapa en mappning:

git config --add git-p4.mapUser "p4user = First Last <mail@address.com>"

Identifiera namnbyten. Se git-diff[1]. Detta kan vara sant, falskt eller en poäng som förväntas av git diff -M.

Identifiera kopior. Se git-diff[1]. Detta kan vara sant, falskt eller en poäng som förväntas av git diff -C.

Upptäck kopior hårdare. Se git-diff[1]. En booleskt värde.

Vid inskick, omredigera ändringarna så att de återspeglar Git-författaren, oavsett vem som anropar git p4 submit.

När preserveUser är sant, dör git p4 normalt om den inte hittar en författare i p4:s användarkarta. Den här inställningen skickar ändringen oavsett.

Skickaprocessen anropar redigeraren innan varje p4-ändring skickas. Om den här inställningen är sann hoppas dock redigeringssteget över.

Efter att ha redigerat p4-ändringsmeddelandet, kontrollerar git p4 att beskrivningen verkligen ändrades genom att titta på filändringstidpunkten. Det här alternativet inaktiverar det testet.

Som standard, kan vilken gren som helst användas som källa för en git p4 submit-operation. Om denna konfigurationsvariabel är inställd, tillåter den endast att de namngivna grenarna används som inskicknings-källor. Grennamn måste vara korta namn (inga "refs/heads/") och ska separeras med kommatecken (",") utan mellanslag.

Om användaren som kör git p4 submit inte finns i p4-användarkartan avslutas git p4. Det här alternativet kan användas för att tvinga fram inlämning oavsett.

Om aktiverat, kommer git p4 submit att försöka rensa RCS-nyckelord ($Header$, etc). Annars skulle dessa orsaka sammanslagningskonflikter och förhindra att inskickningen fortsätter. Det här alternativet bör för närvarande betraktas som experimentellt.

Exportera Git-taggar till p4-etiketter, enligt --export-labels.

Endast p4-etiketter som matchar detta reguljära uttryck kommer att exporteras. Standardvärdet är [a-zA-Z0-9_\-.]+$.

Ange skicka in beteende när en konflikt med p4 hittas, enligt --conflict. Standardbeteendet är ask.

Använd inte en ny bas för trädet mot p4/master efter en inskickning.

Synkronisera inte p4/master med Perforce efter en inskickning. Innebär git-p4.disableRebase.