+git-p4 - Import from and submit to Perforce repositories
+'git p4 clone' [<sync options>] [<clone options>] <p4 depot path>...
+'git p4 sync' [<sync options>] [<p4 depot path>...]
+'git p4 submit' [<submit options>] [<master branch name>]
+This command provides a way to interact with p4 repositories
+Create a new git repository from an existing p4 repository using
+'git p4 clone', giving it one or more p4 depot paths. Incorporate
+new commits from p4 changes with 'git p4 sync'. The 'sync' command
+is also used to include new branches from other p4 depot paths.
+Submit git changes back to p4 using 'git p4 submit'. The command
+'git p4 rebase' does a sync plus rebases the current branch onto
+the updated p4 remote branch.
+* Create an alias for 'git p4', using the full path to the 'git-p4'
+$ git config --global alias.p4 '!git-p4'
+$ git p4 clone //depot/path/project
+* Do some work in the newly created git repository:
+$ git commit -a -m "edited foo.h"
+* Update the git repository with recent changes from p4, rebasing your
+* Submit your commits back to p4:
+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'.
+3. Creates a local branch, 'master' from this remote and checks it out.
+To reproduce the entire p4 history in git, use the '@all' modifier on
+$ git p4 clone //depot/path/project@all
+As development continues in the p4 repository, those changes can
+be included in the git repository using:
+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 //path/in/your/perforce/depot
+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.
+A common working pattern is to fetch the latest changes from the p4 depot
+and merge them with local uncommitted changes. Often, the p4 repository
+is the ultimate location for all code, thus a rebase workflow makes
+sense. This command does 'git p4 sync' followed by 'git rebase' to move
+local commits on top of updated p4 changes.
+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:
+To specify a branch other than the current one, use:
+$ git p4 submit topicbranch
+The upstream reference is generally 'refs/remotes/p4/master', but can
+be overridden using the '--origin=' command-line option.
+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'.
+All commands except clone accept this option.
+ Set the 'GIT_DIR' environment variable. See linkgit:git.
+These options can be used in the initial 'clone' as well as in
+subsequent 'sync' operations.
+ Import changes into given branch. If the branch starts with
+ 'refs/', it will be used as is, otherwise the path 'refs/heads/'
+ will be prepended. The default branch is 'master'. If used
+ with an initial clone, no HEAD will be checked out.
+This example imports a new remote "p4/proj2" into an existing
+ $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
+ Use the branch detection algorithm to find new paths in p4. It is
+ documented below in "BRANCH DETECTION".
+ Import exactly the p4 change numbers listed in 'file', one per
+ line. Normally, 'git p4' inspects the current p4 repository
+ state and detects the changes it should import.
+ Do not print any progress information.
+ Provide more progress information.
+ Query p4 for labels associated with the depot paths, and add
+ By default, p4 branches are stored in 'refs/remotes/p4/',
+ where they will be treated as remote-tracking branches by
+ linkgit:git-branch and other commands. This option instead
+ puts p4 branches in 'refs/heads/p4/'. Note that future
+ sync operations must specify '--import-local' as well so that
+ they can find the p4 branches in refs/heads.
+ Limit the number of imported changes to 'n'. Useful to
+ limit the amount of history when using the '@all' p4 revision
+ 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'.
+ Use a client spec to find the list of interesting files in p4.
+ The client spec is discovered using 'p4 client -o' which checks
+ the 'P4CLIENT' environment variable and returns a mapping of
+ depot files to workspace files. Note that a depot path is
+ still required, but files found in the path that match in
+ the client spec view will be laid out according to the client
+These options can be used in an initial 'clone', along with the 'sync'
+options described above.
+ Where to create the git repository. If not provided, the last
+ component in the p4 depot path is used to create a new
+ Perform a bare clone. See linkgit:git-clone.
+ Exclude selected depot paths when cloning.
+These options can be used to modify 'git p4 submit' behavior.
+ Provide more progress information.
+ Upstream location from which commits are identified to submit to
+ p4. By default, this is the most recent p4 commit reachable
+ Detect renames. See linkgit:git-diff. Renames will be
+ represented in p4 using explicit 'move' operations. There
+ is no corresponding option to detect copies, but there are
+ variables for both moves and copies.
+ Re-author p4 changes before submitting to p4. This option
+ requires p4 admin privileges.
+The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can
+be one or more space-separated p4 depot paths, with an optional
+p4 revision specifier on the end:
+ Import one commit with all files in the '#head' change under that tree.
+ Import one commit for each change in the history of that depot path.
+ Import only changes 1 through 6.
+ Import all changes from both named depot paths into a single
+ repository. Only files below these directories are included.
+ There is not a subdirectory in git for each "proj1" and "proj2".
+ You must use the '--destination' option when specifying more
+ than one depot path. The revision specifier must be specified
+ identically on each depot path. If there are files in the
+ depot paths with the same name, the path with the most recently
+ updated version of the file is the one that appears in git.
+See 'p4 help revisions' for the full syntax of p4 revision specifiers.
+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.
+If you have a repository where all the branches of interest exist as
+subdirectories of a single depot path, you can use '--detect-branches'
+when cloning or syncing to have 'git p4' automatically find
+subdirectories in p4, and to generate these as branches in git.
+For example, if the P4 repository structure is:
+And "p4 branch -o branch1" shows a View line that looks like:
+Then this 'git p4 clone' command:
+git p4 clone --detect-branches //depot@all
+produces a separate branch in 'refs/remotes/p4/' for //depot/main,
+called 'master', and one for //depot/branch1 called 'depot/branch1'.
+However, it is not necessary to create branches in p4 to be able to use
+them like branches. Because it is difficult to infer branch
+relationships automatically, a git configuration setting
+'git-p4.branchList' can be used to explicitly identify branch
+relationships. It is a list of "source:destination" pairs, like a
+simple p4 branch specification, where the "source" and "destination" are
+the path elements in the p4 repository. The example above relied on the
+presence of the p4 branch. Without p4 branches, the same result will
+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
+(linkgit:git-gc) automatically compresses these to fewer pack files,
+but explicit invocation of 'git repack -adf' may improve performance.
+The following config settings can be used to modify 'git p4' behavior.
+They all are in the 'git-p4' section.
+ User specified as an option to all p4 commands, with '-u <user>'.
+ The environment variable 'P4USER' can be used instead.
+ Password specified as an option to all p4 commands, with
+ The environment variable 'P4PASS' can be used instead.
+ Port specified as an option to all p4 commands, with
+ The environment variable 'P4PORT' can be used instead.
+ Host specified as an option to all p4 commands, with
+ The environment variable 'P4HOST' can be used instead.
+ Client specified as an option to all p4 commands, with
+ '-c <client>'. This can also be used as a way to find
+ the client spec for the 'useClientSpec' option.
+ The environment variable 'P4CLIENT' can be used instead.
+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.
+ One phase in branch detection involves looking at p4 branches
+ to find new ones to import. By default, all branches are
+ inspected. This option limits the search to just those owned
+ by the single user named in the variable.
+ List of branches to be imported when branch detection is
+ enabled. Each entry should be a pair of branch names separated
+ by a colon (:). This example declares that both branchA and
+ branchB were created from main:
+git config git-p4.branchList main:branchA
+git config --add git-p4.branchList main:branchB
+ Specify that the p4 client spec to be used to identify p4 depot
+ paths of interest. This is equivalent to specifying the option
+ '--use-client-spec'. The variable 'git-p4.client' can be used
+ to specify the name of the client.
+ Detect renames. See linkgit:git-diff.
+ Detect copies. See linkgit:git-diff.
+ Detect copies harder. See linkgit:git-diff.
+ On submit, re-author changes to reflect the git author,
+ regardless of who invokes 'git p4 submit'.
+ When 'preserveUser' is true, 'git p4' normally dies if it
+ cannot find an author in the p4 user map. This setting
+ submits the change regardless.
+ The submit process invokes the editor before each p4 change
+ is submitted. If this setting is true, though, the editing
+ After editing the p4 change message, 'git p4' makes sure that
+ the description really was changed by looking at the file
+ modification time. This option disables that test.
+ By default, any branch can be used as the source for a 'git p4
+ submit' operation. This configuration variable, if set, permits only
+ the named branches to be used as submit sources. Branch names
+ must be the short names (no "refs/heads/"), and should be
+ separated by commas (","), with no spaces.
+ If the user running 'git p4 submit' does not exist in the p4
+ user map, 'git p4' exits. This option can be used to force
+* Changesets from p4 are imported using git fast-import.
+* Cloning or syncing does not require a p4 client; file contents are
+ collected using 'p4 print'.
+* 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.
+* Each commit imported by 'git p4' has a line at the end of the log
+ message indicating the p4 depot location and change number. This
+ line is used by later 'git p4 sync' operations to know which p4