consult the client spec when given the `--use-client-spec` option or
when the useClientSpec variable is true.  After 'git p4 clone', the
useClientSpec variable is automatically set in the repository
configuration file.  This allows future 'git p4 submit' commands to
work properly; the submit command looks only at the variable and does
not have a command-line option.

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.

Bugs in the implementation of overlap mappings exist.  If multiple depot
paths map through overlays to the same location in the repository,
'git p4' can choose the wrong one.  This is hard to solve without
dedicating a client spec just for 'git p4'.

The name of the client can be given to 'git p4' in multiple ways.  The
variable 'git-p4.client' takes precedence if it exists.  Otherwise,
normal p4 mechanisms of determining the client are used:  environment
variable `P4CLIENT`, a file referenced by `P4CONFIG`, or the local host name.


BRANCH DETECTION
----------------
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:

----
//depot/main/...
//depot/branch1/...
----

And "p4 branch -o branch1" shows a View line that looks like:

----
//depot/main/... //depot/branch1/...
----

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
occur with:

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


PERFORMANCE
-----------
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[1]) automatically compresses these to fewer pack files,
but explicit invocation of 'git repack -adf' may improve performance.


CONFIGURATION VARIABLES
-----------------------
The following config settings can be used to modify 'git p4' behavior.
They all are in the 'git-p4' section.

General variables
~~~~~~~~~~~~~~~~~
git-p4.user::
	User specified as an option to all p4 commands, with '-u <user>'.
	The environment variable `P4USER` can be used instead.

git-p4.password::
	Password specified as an option to all p4 commands, with
	'-P <password>'.
	The environment variable `P4PASS` can be used instead.

git-p4.port::
	Port specified as an option to all p4 commands, with
	'-p <port>'.
	The environment variable `P4PORT` can