Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Documentation | 2025.2

# p4 push

Copy submitted files in your local server to a remote server.

For distributed version control. See P4 Server Administration Documentation (DVCS).

## Syntax

    p4 [g-opts] push [-n -v] [-r remotespec] [-Ox] [-S stream | filespec]
    p4 [g-opts] push [-n -v] [-r remotespec] [-Ox] -s shelf

Syntax and naming conventions

## Description

(DVCS) The `p4 push` copies the following items from the specified local server to the remote server:

- the specified set of files
- the changelists that submitted those files
- the files' attributes
- any fixes associated with the changelists, but only if the job that is associated with the fix is already present in the remote server. If it is not, then the fix is not copied.
- all integration records that describe integrations to the files being pushed

A push is only allowed if the files being pushed fit cleanly into the remote server, building precisely on a shared common history. If there are any conflicts or gaps, the push is rejected. Otherwise, the changelists become new submitted changelists in the remote server.

The second form of the command pushes a shelved changelist, rather than one or more submitted changelists, which avoids conflicts. The result is a new shelved change in the remote server.

When the changelists are added to the remote server, they are given newly assigned change numbers, but they retain the same description, user, date, type, workspace, and set of files.

When the files are added to the remote server, they are kept in their same changelists, as new revisions starting after the current head. The new revisions retain the same revision number, file type, action, date, timestamp, digest, and file size.

Although the changelists are new submitted changelists in the remote server, none of the submit triggers are run in the remote server.

If a particular revision of a file has been copied from ServerA to ServerB and ServerC, changing the attributes on that revision on ServerB by using `p4 attribute -f` only affect the revision on ServerB.

When changes are pushed or fetched, the Type: field for changes ignores the setting of the defaultChangeType configurable on the target server.

Typically, the `p4 push` command specifies a remote spec, and the `DepotMap` field in the remote spec specifies which files are to be pushed. The `p4 push` command can also specify a filespec argument to further restrict the files to be pushed. If the remote spec uses differing patterns for the local and remote sides of the `DepotMap`, the filespec argument, if provided, must specify the files using the local filename syntax.

If a particular changelist includes some files that match the filespec, and other files that do not, then only the matching files are included in the push. To ensure that a partial changelist is not pushed, an appropriate filespec should be specified (for example, `//...@change,#head`).

The integration records describing integrations to the files being pushed are adjusted in the remote server to reflect the resulting changelist numbers and revision numbers of the remote server.

To push a set of files, you must have read access to those files in the local server, and you must have write access to those same files in the remote server (according to the remote server’s protections table). Your local userid is also used as the userid at the remote server and you must already be logged in to both servers prior to running the `p4 push` command.

The `p4 push` command is atomic: either all the specified files are pushed, or none of them are pushed.

The value of the `rpl.checksum.change` configurable determines the level of verification performed for the `p4 push` command. See Configurables.

### Triggering on pushes

The following push trigger types can be invoked during the execution of the `p4 push` command:

- The `push-submit` trigger can customize processing during the phase of the `p4 push` command when metadata has been transferred but files have not yet been transferred.
- The `push-content` trigger can customize processing during that phase of the `p4 push` command when files have been transferred but their contents have not yet been committed.
- The `push-commit` trigger can do any clean up work or other post processing after changes have been committed by the `p4 push` command.

For more information, see the section Triggering on pushes and fetches in the scripting chapter of P4 Server Administration Documentation.

## Options

If the `-r` option is not specified, `p4 push` pushes files to the remote server named origin.

By default, changes cannot be pushed from server to server; in order to push changes between servers, an administrator of each server must enable pushing. Set `server.allowpush` to `1` on the server which initiates the push; set `server.allowpush` to `2` on the destination server. Files with the filetype modifiers `+k`, `+l`, or `+S` have some special considerations. Files of type `+k` have their digests cleared when pushed. This means certain cross-server merge conflicts are not detected. To re-generate the digests in the remote server after the push, use `p4 verify`.

When pushing files of type `+l`, the new files are added to the remote server even if the files are currently open by a pending changelist in that server. When pushing files of type `+S`, old archives which exceed the specified limit are not purged by the `p4 push` command.

Option | Description
--- | ---
`-n` | Performs all the correctness checks, but does not push any files or changelists to the remote server.
`-Oc` | When set, the `p4 push` command outputs information about every changelist. The `-v` option must be set for this to take effect.
`-Of` | When set, the `p4 push` command outputs information about every file in every changelist. The `-v` option must be set for this to take effect.
`-Oi` | When set, the `p4 push` command outputs information about every integration in every file in every changelist. The `-v` option must be set for this to take effect.
`-r remotespec` | Specifies a remote spec which contains the address of the remote server, and a file mapping which is to be used to re-map the files when they are pushed to the remote server.
--remote-user | Can be used to specify the username for the target server, overriding any RemoteUser field in the remote spec. (See p4 remote)
`-s` | Specifies a shelved changelist to be pushed, instead of one or more submitted changelists. For more information, see the section "Fetch and push a shelved changelist" in the "Fetching and Pushing" chapter of P4 Server Administration Documentation.
`-S stream` | Specifies a particular stream to push. If you specify a stream you cannot also specify a file or files.
`-v` | Specifies verbose mode, which provides diagnostics for debugging. You must opt in to verbose mode. With verbose mode turned on, you can refine and control the precise level of verbosity. Specifically, you can indicate whether you want information about: every changelist pushed (with the `-Oc` option) every file in every changelist pushed (with the `-Of` option) every integration of every file in every changelist pushed (with the `-Oi` option) You can specify any combination of these options. The default is to display information about every changelist.
`filespec` | Specifies which file or files to push. If you specify a file or files you cannot specify a stream with the `-S` option.

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
N/A | N/A | read on the local server, `write` on the remote server.

## Examples

`p4 push -r bruno-remote` | Push a file or files that are specified in the remote spec.

## Related commands

Copy files from a remote server into your local server | `p4 fetch`

Your search for returned results