`--no-verify` command line option.

One usage scenario is to run unit tests in the hook.

p4-prepare-changelist
~~~~~~~~~~~~~~~~~~~~~

The `p4-prepare-changelist` hook is executed right after preparing
the default changelist message and before the editor is started.
It takes one parameter, the name of the file that contains the
changelist text. Exiting with a non-zero status from the script
will abort the process.

The purpose of the hook is to edit the message file in place,
and it is not suppressed by the `--no-verify` option. This hook
is called even if `--prepare-p4-only` is set.

p4-changelist
~~~~~~~~~~~~~

The `p4-changelist` hook is executed after the changelist
message has been edited by the user. It can be bypassed with the
`--no-verify` option. It takes a single parameter, the name
of the file that holds the proposed changelist text. Exiting
with a non-zero status causes the command to abort.

The hook is allowed to edit the changelist file and can be used
to normalize the text into some project standard format. It can
also be used to refuse the Submit after inspect the message file.

p4-post-changelist
~~~~~~~~~~~~~~~~~~

The `p4-post-changelist` hook is invoked after the submit has
successfully occurred in P4. It takes no parameters and is meant
primarily for notification and cannot affect the outcome of the
git p4 submit action.



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

--import-labels::
	Import p4 labels.

Unshelve options
~~~~~~~~~~~~~~~~

--origin::
    Sets the git refspec against which the shelved P4 changelist is compared.
    Defaults to p4/master.

DEPOT PATH SYNTAX
-----------------
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:

"//depot/my/project"::
    Import one commit with all files in the '#head' change under that tree.

"//depot/my/project@all"::
    Import one commit for each change in the history of that depot path.

"//depot/my/project@1,6"::
    Import only changes 1 through 6.

"//depot/proj1@all //depot/proj2@all"::
    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.


CLIENT SPEC
-----------
The p4 client specification is maintained with the 'p4 client' command
and contains among other fields, a View that specifies how the depot
is mapped into the client repository.  The 'clone' and 'sync' commands
can 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