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
    $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
----

--detect-branches::
	Use the branch detection algorithm to find new paths in p4.  It is
	documented below in "BRANCH DETECTION".

--changesfile <file>::
	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.

--silent::
	Do not print any progress information.

--detect-labels::
	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::
	Import labels from p4 into Git.

--import-local::
	By default, p4 branches are stored in 'refs/remotes/p4/',
	where they will be treated as remote-tracking branches by
	linkgit:git-branch[1] 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.

--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.

--keep-path::
	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-client-spec::
	Use a client spec to find the list of interesting files in p4.
	See the "CLIENT SPEC" section below.

-/ <path>::
	Exclude selected depot paths when cloning or syncing.

Clone options
~~~~~~~~~~~~~
These options can be used in an initial 'clone', along with the 'sync'
options described above.

--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.

--bare::
	Perform a bare clone.  See linkgit:git-clone[1].

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

--origin <commit>::
	Upstream location from which commits are identified to submit to
	p4.  By default, this is the most recent p4 commit reachable
	from `HEAD`.

-M::
	Detect renames.  See linkgit:git-diff[1].  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.

--preserve-user::
	Re-author p4 changes before submitting to p4.  This option
	requires p4 admin privileges.

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

-n::
--dry-run::
	Show just what commits would be submitted to p4; do not change
	state in Git or p4.

--prepare-p4-only::
	Apply a commit to the p4 workspace, opening, adding and deleting
	files in p4 as