git p4 clone [<sync options>] [<clone options>] <p4 depot path>…​
git p4 sync [<sync options>] [<p4 depot path>…​]
git p4 rebase


This command provides a way to interact with p4 repositories using Git.



  • Clone a repository:

    $ git p4 clone //depot/path/project
  • Do some work in the newly created Git repository:

    $ cd project
    $ vi foo.h
    $ git commit -a -m "edited foo.h"
  • Update the Git repository with recent changes from p4, rebasing your work on top:

    $ git p4 rebase
  • Submit your commits back to p4:

    $ git p4 submit



Generally, git p4 clone is used to create a new Git directory from an existing p4 repository:

$ git p4 clone //depot/path/project


  1. Creates an empty Git repository in a subdirectory called project.

  2. Imports the full contents of the head revision from the given p4 depot path into a single commit in the Git branch refs/remotes/p4/master.


To reproduce the entire p4 history in Git, use the @all modifier on the depot path:



As development continues in the p4 repository, those changes can be included in the Git repository using:

$ git p4 sync

This command finds new changes in p4 and imports them as Git commits.

P4 repositories can be added to an existing Git repository using git p4 sync too:

$ mkdir repo-git
$ cd repo-git
$ git init

This imports the specified depot into refs/remotes/p4/master in an existing Git repository. The --branch option can be used to specify a different branch to be used for the p4 content.

If a Git repository includes branches refs/remotes/origin/p4, these will be fetched and consulted first during a git p4 sync. Since importing directly from p4 is considerably slower than pulling changes from a Git remote, this can be useful in a multi-developer environment.

If there are multiple branches, doing git p4 sync will automatically use the "BRANCH DETECTION" algorithm to try to partition new changes into the right branch. This can be overridden with the --branch option to specify just a single branch to update.



$ git p4 rebase


Submitting changes from a Git repository back to the p4 repository requires a separate p4 client workspace. This should be specified using the P4CLIENT environment variable or the Git configuration variable git-p4.client. The p4 client must exist, but the client root will be created and populated if it does not already exist.

To submit all changes that are in the current Git branch but not in the p4/master branch, use:

$ git p4 submit

To specify a branch other than the current one, use:

$ git p4 submit topicbranch


The p4 changes will be created as the user invoking git p4 submit. The --preserve-user option will cause ownership to be modified according to the author of the Git commit. This option requires admin privileges in p4, which can be granted using p4 protect.


General options

All commands except clone accept these options.

--git-dir <dir>

Set the GIT_DIR environment variable. See git(1).


Provide more progress information.

Sync options


--branch <ref>

Import changes into <ref> instead of refs/remotes/p4/master. If <ref> starts with refs/, it is used as is. Otherwise, if it does not start with p4/, that prefix is added.

By default a <ref> not starting with refs/ is treated as the name of a remote-tracking branch (under refs/remotes/). This behavior can be modified using the --import-local option.

The default <ref> is "master".

This example imports a new remote "p4/proj2" into an existing Git repository:

    $ git init


--changesfile <file>



Do not print any progress information.


Query p4 for labels associated with the depot paths, and add them as tags in Git. Limited usefulness as only imports labels associated with new changelists. Deprecated.


Import labels from p4 into Git.



--max-changes <n>

Import at most n changes, rather than the entire range of changes included in the given revision specifier. A typical usage would be use @all as the revision specifier, but then to use --max-changes 1000 to import only the last 1000 revisions rather than the entire revision history.

--changes-block-size <n>

The internal block size to use when converting a revision specifier such as @all into a list of specific change numbers. Instead of using a single call to p4 changes to find the full list of changes for the conversion, there are a sequence of calls to p4 changes -m, each of which requests one block of changes of the given size. The default block size is 500, which should usually be suitable.


The mapping of file names from the p4 depot path to Git, by default, involves removing the entire depot path. With this option, the full p4 depot path is retained in Git. For example, path //depot/main/foo/bar.c, when imported from //depot/main/, becomes foo/bar.c. With --keep-path, the Git path is instead depot/main/foo/bar.c.



-/ <path>

Exclude selected depot paths when cloning or syncing.

Clone options


--destination <directory>

Where to create the Git repository. If not provided, the last component in the p4 depot path is used to create a new directory.



Submit options

These options can be used to modify git p4 submit behavior.

--origin <commit>







Export tags from Git as p4 labels. Tags found in Git are applied to the perforce working directory.


Show just what commits would be submitted to p4; do not change state in Git or p4.





--branch <branch>

After submitting, sync this named branch instead of the default p4/master. See the "Sync options" section above for more information.

Rebase options

These options can be used to modify git p4 rebase behavior.


Import p4 labels.








Import only changes 1 through 6.






The full syntax for a p4 view is documented in p4 help views. git p4 knows only a subset of the view syntax. It understands multi-line mappings, overlays with +, exclusions with - and double-quotes around whitespace. Of the possible wildcards, git p4 only handles …​, and only when it is at the end of the path. git p4 will complain if it encounters an unhandled wildcard.




P4 does not have the same concept of a branch as Git. Instead, p4 organizes its content as a directory tree, where by convention different logical branches are in different locations in the tree. The p4 branch command is used to maintain mappings between different areas in the tree, and indicate related content. git p4 can use these mappings to determine branch relationships.


For example, if the P4 repository structure is:




Then this git p4 clone command:




git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all .


The fast-import mechanism used by git p4 creates one pack file for each invocation of git p4 sync. Normally, Git garbage compression (git-gc(1)) automatically compresses these to fewer pack files, but explicit invocation of git repack -adf may improve performance.



General variables










Clone and sync variables


Because importing commits from other Git repositories is much faster than importing them from p4, a mechanism exists to find p4 changes first in Git remotes. If branches exist under refs/remote/origin/p4, those will be fetched and used when syncing from p4. This variable can be set to false to disable this behavior.





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





Only p4 labels matching this regular expression will be imported. The default value is [a-zA-Z0-9_\-.]+$.




Perforce keeps the encoding of a path as given by the originating OS. Git expects paths encoded as UTF-8. Use this config to tell git-p4 what encoding Perforce had used for the paths. This encoding is used to transcode the paths to UTF-8. As an example, Perforce on Windows often uses "cp1252" to encode path names.


Specify the system that is used for large (binary) files. Please note that large file systems do not support the git p4 submit command. Only Git LFS is implemented right now (see for more information). Download and install the Git LFS command line extension to use this option and configure it like this:

git config       git-p4.largeFileSystem GitLFS

All files matching a file extension in the list will be processed by the large file system. Do not prefix the extensions with ..


All files with an uncompressed size exceeding the threshold will be processed by the large file system. By default the threshold is defined in bytes. Add the suffix k, m, or g to change the unit.


All files with a compressed size exceeding the threshold will be processed by the large file system. This option might slow down your clone/sync process. By default the threshold is defined in bytes. Add the suffix k, m, or g to change the unit.


Boolean variable which defines if large files are automatically pushed to a server.


A changelist that contains only excluded files will be imported as an empty commit if this boolean option is set to true.


Map a P4 user to a name and email address in Git. Use a string with the following format to create a mapping:

git config --add git-p4.mapUser "p4user = First Last <>"

A mapping will override any user information from P4. Mappings for multiple P4 user can be defined.

Submit variables








On submit, re-author changes to reflect the Git author, regardless of who invokes git p4 submit.














Export Git tags to p4 labels, as per --export-labels.






  • Changesets from p4 are imported using Git fast-import.


  • Submitting requires a p4 client, which is not in the same location as the Git repository. Patches are applied, one at a time, to this p4 client and submitted from there.
