Setzt die Umgebungsvariable GIT_DIR. Siehe git[1].

Gibt mehr Fortschrittsinformationen aus.

Importiert Änderungen in <ref> anstelle von refs/remotes/p4/master. Wenn <ref> mit refs/ beginnt, wird es so verwendet, wie es ist. Andernfalls, wenn es nicht mit p4/ beginnt, wird dieser Präfix hinzugefügt.

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

Verwendet den Branch-Erkennungsalgorithmus, um neue Pfade in p4 zu finden. Er wird unten unter "BRANCH DETECTION" dokumentiert.

Importiert exakt die p4 Change-Nummern, die in file aufgelistet sind, eine pro Zeile. Normalerweise inspiziert git p4 den aktuellen p4 Repository-Status und erkennt die Änderungen, die es importieren sollte.

Gibt keine Fortschrittsinformationen aus.

Fragt p4 nach Labels ab, die mit den Depot-Pfaden assoziiert sind, und fügt sie als Tags in Git hinzu. Begrenzte Nützlichkeit, da nur Labels importiert werden, die mit neuen Changelisten assoziiert sind. Veraltet.

Importiert Labels von p4 nach Git.

Standardmäßig werden p4-Branches in refs/remotes/p4/ gespeichert, wo sie von git-branch[1] und anderen Befehlen als Remote-Tracking-Branches behandelt werden. Diese Option platziert p4-Branches stattdessen in refs/heads/p4/. Beachten Sie, dass zukünftige Sync-Operationen ebenfalls --import-local angeben müssen, damit sie die p4-Branches in refs/heads finden können.

Importiert maximal n Änderungen anstelle des gesamten Bereichs von Änderungen, der im angegebenen Revisionsspezifizierer enthalten ist. Eine typische Verwendung wäre die Verwendung von @all als Revisionsspezifizierer, aber dann die Verwendung von --max-changes 1000, um nur die letzten 1000 Revisionen anstelle der gesamten Revisionshistorie zu importieren.

Die interne Blockgröße, die beim Konvertieren eines Revisionsspezifizierers wie @all in eine Liste spezifischer Change-Nummern verwendet wird. Anstatt eines einzigen Aufrufs von p4 changes zu verwenden, um die vollständige Liste der Änderungen für die Konvertierung zu ermitteln, gibt es eine Sequenz von Aufrufen von p4 changes -m, die jeweils einen Block von Änderungen der angegebenen Größe anfordern. Die Standardblockgröße beträgt 500, was normalerweise ausreichend sein sollte.

Die Zuordnung von Dateinamen vom p4 Depot-Pfad zu Git beinhaltet standardmäßig das Entfernen des gesamten Depot-Pfads. Mit dieser Option bleibt der vollständige p4 Depot-Pfad in Git erhalten. Beispielsweise wird der Pfad //depot/main/foo/bar.c, wenn er von //depot/main/ importiert wird, zu foo/bar.c. Mit --keep-path ist der Git-Pfad stattdessen depot/main/foo/bar.c.

Verwendet eine Client-Spezifikation, um die Liste der interessanten Dateien in p4 zu ermitteln. Siehe den Abschnitt "CLIENT SPEC" unten.

Schließt ausgewählte Depot-Pfade beim Klonen oder Synchronisieren aus.

Wo das Git-Repository erstellt werden soll. Wenn nicht angegeben, wird die letzte Komponente des p4 Depot-Pfads verwendet, um ein neues Verzeichnis zu erstellen.

Führt einen Bare-Clone durch. Siehe git-clone[1].

Upstream-Speicherort, von dem Commits identifiziert werden, die an p4 übermittelt werden. Standardmäßig ist dies der neueste p4 Commit, der von HEAD erreichbar ist.

Benennungen erkennen. Siehe git-diff[1]. Benennungen werden in p4 durch explizite move Operationen dargestellt. Es gibt keine entsprechende Option, um Kopien zu erkennen, aber es gibt Variablen für sowohl Moves als auch Copies.

P4-Änderungen neu authorn, bevor sie an p4 übermittelt werden. Diese Option erfordert P4-Admin-Privilegien.

Exportiert Tags von Git als p4 Labels. Tags, die in Git gefunden werden, werden auf das Perforce-Arbeitsverzeichnis angewendet.

Zeigt nur an, welche Commits an p4 übermittelt würden; ändert den Zustand in Git oder p4 nicht.

Wendet einen Commit auf den p4-Workspace an, öffnet, fügt hinzu und löscht Dateien in p4 wie bei einer normalen Submit-Operation. Führt nicht das abschließende "p4 submit" aus, sondern gibt eine Meldung aus, wie manuell eingereicht oder rückgängig gemacht werden kann. Diese Option stoppt immer nach dem ersten (ältesten) Commit. Git-Tags werden nicht an p4 exportiert.

Anstatt einzureichen, werden eine Reihe von gespeicherten Changelists erstellt. Nach dem Erstellen jedes Shelves werden die relevanten Dateien rückgängig gemacht/gelöscht. Wenn Sie mehrere Commits ausstehend haben, werden mehrere Shelves erstellt.

Aktualisiert eine bestehende gespeicherte Changelist mit diesem Commit. Impliziert --shelve. Wiederholen Sie dies für mehrere gespeicherte Changelists.

Konflikte können beim Anwenden eines Commits auf p4 auftreten. Wenn dies geschieht, ist das Standardverhalten ("ask") die Aufforderung, ob dieser Commit übersprungen und fortgefahren werden soll, oder ob abgebrochen werden soll. Diese Option kann verwendet werden, um die Eingabeaufforderung zu umgehen, sodass konfligierende Commits automatisch übersprungen werden, oder um den Versuch, Commits anzuwenden, ohne Aufforderung abzubrechen.

Nach dem Einreichen werden diese benannte Branch anstelle von p4/master synchronisiert. Siehe den Abschnitt "Sync-Optionen" oben für weitere Informationen.

Reichen Sie nur den angegebenen Commit oder Bereich von Commits ein, anstatt die vollständige Liste der Änderungen im aktuellen Git-Branch.

Deaktiviert das automatische Rebase, nachdem alle Commits erfolgreich übermittelt wurden. Kann auch mit git-p4.disableRebase gesetzt werden.

Deaktiviert das automatische Synchronisieren von p4/master von Perforce nach der Übermittlung von Commits. Impliziert --disable-rebase. Sync mit origin/master wird weiterhin durchgeführt, wenn möglich. Kann auch mit git-p4.disableP4Sync gesetzt werden.

Importiert p4 Labels.

Legt die Git-Refspec fest, gegen die die gespeicherte P4-Changeliste verglichen wird. Standard ist p4/master.

Benutzer, der als Option für alle p4-Befehle mit -u <user> angegeben wird. Die Umgebungsvariable P4USER kann stattdessen verwendet werden.

Passwort, das als Option für alle p4-Befehle mit -P <password> angegeben wird. Die Umgebungsvariable P4PASS kann stattdessen verwendet werden.

Port, der als Option für alle p4-Befehle mit -p <port> angegeben wird. Die Umgebungsvariable P4PORT kann stattdessen verwendet werden.

Host, der als Option für alle p4-Befehle mit -h <host> angegeben wird. Die Umgebungsvariable P4HOST kann stattdessen verwendet werden.

Client, der als Option für alle p4-Befehle mit -c <client> angegeben wird, einschließlich der Client-Spezifikation.

Gibt an, wie oft ein p4-Befehl (insbesondere p4 sync) wiederholt werden soll, wenn das Netzwerk ausfällt. Der Standardwert ist 3. Setzen Sie den Wert auf 0, um Wiederholungen zu deaktivieren oder wenn Ihre p4-Version keine Wiederholungen unterstützt (vor 2012.2).

Da das Importieren von Commits aus anderen Git-Repositories viel schneller ist als das Importieren aus p4, gibt es einen Mechanismus, um p4-Änderungen zuerst in Git-Remotes zu finden. Wenn Branches unter refs/remote/origin/p4 existieren, werden diese abgerufen und beim Synchronisieren mit p4 verwendet. Diese Variable kann auf false gesetzt werden, um dieses Verhalten zu deaktivieren.

Eine Phase der Branch-Erkennung beinhaltet die Untersuchung von p4-Branches, um neue zu importierende zu finden. Standardmäßig werden alle Branches inspiziert. Diese Option beschränkt die Suche auf die Branches, die dem in der Variable angegebenen einzelnen Benutzer gehören.

Liste der Branches, die bei aktivierter Branch-Erkennung importiert werden sollen. Jeder Eintrag sollte ein Paar von Branch-Namen sein, die durch einen Doppelpunkt (:) getrennt sind. Dieses Beispiel deklariert, dass sowohl branchA als auch branchB von main erstellt wurden.

git config       git-p4.branchList main:branchA
git config --add git-p4.branchList main:branchB

Liste der zu ignorierenden p4 Labels. Dies wird automatisch aufgebaut, wenn nicht importierbare Labels entdeckt werden.

Importiert p4 Labels nach git, gemäß --import-labels.

Nur p4 Labels, die diesem regulären Ausdruck entsprechen, werden importiert. Der Standardwert ist [a-zA-Z0-9_\-.]+$.

Gibt an, dass die p4 Client-Spezifikation verwendet werden soll, um die interessanten p4 Depot-Pfade zu identifizieren. Dies ist äquivalent zur Angabe der Option --use-client-spec. Siehe den Abschnitt "CLIENT SPEC" oben. Diese Variable ist ein boolescher Wert, nicht der Name eines p4 Clients.

Perforce speichert die Kodierung eines Pfades, wie sie vom ursprünglichen Betriebssystem stammt. Git erwartet Pfade, die als UTF-8 kodiert sind. Verwenden Sie diese Konfiguration, um git-p4 mitzuteilen, welche Kodierung Perforce für die Pfade verwendet hat. Diese Kodierung wird verwendet, um die Pfade in UTF-8 zu transkodieren. Zum Beispiel verwendet Perforce unter Windows oft "cp1252", um Pfadnamen zu kodieren. Wenn diese Option in eine p4 clone-Anfrage übergeben wird, wird sie im resultierenden neuen git-Repository gespeichert.

Perforce behält die Kodierung von Changelist-Beschreibungen und vollständigen Benutzernamen bei, wie sie vom Client auf einem bestimmten Betriebssystem gespeichert wurden. Der p4v-Client verwendet die lokal auf dem Betriebssystem kodierte Zeichen. Daher können verschiedene Benutzer unterschiedliche Changelist-Beschreibungen oder vollständige Benutzernamen in unterschiedlichen Kodierungen im selben Depot speichern. Git toleriert inkonsistente/fehlerhafte Kodierungen in Commit-Nachrichten und Autorennamen, erwartet jedoch, dass sie in UTF-8 angegeben sind. git-p4 kann drei verschiedene Dekodierungsstrategien verwenden, um die Unsicherheit der Kodierung in Perforce zu handhaben: passthrough gibt einfach die ursprünglichen Bytes von Perforce an Git weiter, wodurch brauchbare, aber falsch kodierte Daten entstehen, wenn die Perforce-Daten anders als UTF-8 kodiert sind. strict erwartet, dass die Perforce-Daten als UTF-8 kodiert sind, und schlägt fehl, wenn dies nicht der Fall ist. fallback versucht, die Daten als UTF-8 zu interpretieren, und greift andernfalls auf eine sekundäre Kodierung zurück – standardmäßig die gängige Windows-Kodierung cp-1252 – wobei Zeichen im oberen Bereich maskiert werden, wenn die Dekodierung mit der Fallback-Kodierung ebenfalls fehlschlägt. Unter Python 2 ist die Standardstrategie aus historischen Gründen passthrough, und unter Python 3 ist die Standardstrategie fallback. Wenn strict ausgewählt ist und die Dekodierung fehlschlägt, schlägt die Fehlermeldung vor, diesen Konfigurationsparameter als Workaround zu ändern. Wenn diese Option in eine p4 clone-Anfrage übergeben wird, wird sie im resultierenden neuen git-Repository gespeichert.

Gibt die Fallback-Kodierung an, die beim Dekodieren von Perforce-Autorennamen und Changelist-Beschreibungen mit der Strategie fallback verwendet wird (siehe git-p4.metadataDecodingStrategy). Die Fallback-Kodierung wird nur verwendet, wenn die Dekodierung als UTF-8 fehlschlägt. Diese Option ist standardmäßig auf cp1252 eingestellt, eine gängige Windows-Kodierung. Wenn diese Option in eine p4 clone-Anfrage übergeben wird, wird sie im resultierenden neuen git-Repository gespeichert.

Gibt das System an, das für große (binäre) Dateien verwendet wird. Bitte beachten Sie, dass große Dateisysteme den Befehl git p4 submit nicht unterstützen. Derzeit ist nur Git LFS implementiert (siehe https://git-lfs.github.com/ für weitere Informationen). Laden Sie die Git LFS Kommandozeilen-Erweiterung herunter und installieren Sie sie, um diese Option zu verwenden, und konfigurieren Sie sie wie folgt

git config       git-p4.largeFileSystem GitLFS

Alle Dateien, die mit einer Dateiendung in der Liste übereinstimmen, werden vom großen Dateisystem verarbeitet. Fügen Sie den Erweiterungen kein "." voran.

Alle Dateien mit einer unkomprimierten Größe, die den Schwellenwert überschreitet, werden vom großen Dateisystem verarbeitet. Standardmäßig ist der Schwellenwert in Bytes definiert. Fügen Sie die Suffixe k, m oder g hinzu, um die Einheit zu ändern.

Alle Dateien mit einer komprimierten Größe, die den Schwellenwert überschreitet, werden vom großen Dateisystem verarbeitet. Diese Option kann Ihren Clone/Sync-Prozess verlangsamen. Standardmäßig ist der Schwellenwert in Bytes definiert. Fügen Sie die Suffixe k, m oder g hinzu, um die Einheit zu ändern.

Boolesche Variable, die definiert, ob große Dateien automatisch auf einen Server gepusht werden.

Eine Changelist, die nur ausgeschlossene Dateien enthält, wird als leerer Commit importiert, wenn diese boolesche Option auf true gesetzt ist.

Ordnet einen P4-Benutzer einem Namen und einer E-Mail-Adresse in Git zu. Verwenden Sie eine Zeichenkette mit dem folgenden Format, um ein Mapping zu erstellen

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

Benennungen erkennen. Siehe git-diff[1]. Dies kann true, false oder ein Score sein, wie von git diff -M erwartet.

Kopien erkennen. Siehe git-diff[1]. Dies kann true, false oder ein Score sein, wie von git diff -C erwartet.

Kopien schwieriger erkennen. Siehe git-diff[1]. Ein boolescher Wert.

Beim Submit die Änderungen neu authorn, um den Git-Autor widerzuspiegeln, unabhängig davon, wer git p4 submit aufruft.

Wenn preserveUser true ist, stirbt git p4 normalerweise, wenn es einen Autor in der p4 Benutzerzuordnung nicht finden kann. Diese Einstellung reicht die Änderung trotzdem ein.

Der Submit-Prozess ruft den Editor auf, bevor jede p4-Änderung übermittelt wird. Wenn diese Einstellung true ist, wird der Bearbeitungsschritt jedoch übersprungen.

Nach der Bearbeitung der p4-Änderungsnachricht stellt git p4 sicher, dass die Beschreibung tatsächlich geändert wurde, indem es die Datei-Änderungszeit prüft. Diese Option deaktiviert diesen Test.

Standardmäßig kann jeder Branch als Quelle für eine git p4 submit Operation verwendet werden. Diese Konfigurationsvariable, falls gesetzt, erlaubt nur die Benennung der angegebenen Branches als Submit-Quellen. Branch-Namen müssen die Kurznamen sein (kein "refs/heads/"), und sollten durch Kommas (",") getrennt werden, ohne Leerzeichen.

Wenn der Benutzer, der git p4 submit ausführt, nicht in der p4 Benutzerzuordnung vorhanden ist, beendet sich git p4. Diese Option kann verwendet werden, um die Einreichung unabhängig davon zu erzwingen.

Wenn aktiviert, versucht git p4 submit, RCS-Schlüsselwörter ($Header$, etc.) zu bereinigen. Diese würden andernfalls Merge-Konflikte verursachen und den Submit verhindern. Diese Option sollte derzeit als experimentell betrachtet werden.

Exportiert Git-Tags nach p4 Labels, wie bei --export-labels.

Nur p4 Labels, die diesem regulären Ausdruck entsprechen, werden exportiert. Der Standardwert ist [a-zA-Z0-9_\-.]+$.

Gibt das Submit-Verhalten an, wenn ein Konflikt mit p4 gefunden wird, wie bei --conflict. Das Standardverhalten ist ask.

Der Baum wird nach einem Submit nicht gegen p4/master gerebased.

Nach einem Submit wird p4/master nicht mit Perforce synchronisiert. Impliziert git-p4.disableRebase.