p4 fetch


Copy files from a remote server into the server to which you're currently connected.


p4 [g-opts] fetch [-r remotespec] [-m depth] [-v -k] [-n | -u] [-S stream | filespec]


The p4 fetch command copies from the specified remote server the specified set of files, and the changelists which submitted those files, into the local server. A fetch is only allowed if the files being fetched fit cleanly into the server to which you're currently connected, building precisely on a shared common history.

If there are no conflicts, the files and their changelists become new submitted changelists in this server. Conflict handling is configurable, using the -u option. If -u is not specified, and there are any conflicts or gaps, the fetch is rejected. The -u option specifies that the conflicting changelists should be unsubmitted, and the remote work is then fetched. After the fetch completes, use p4 resubmit to resubmit the conflicting local changes.

When the changelists are added to this 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 this 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 this server, none of the submit triggers are run in this server.

Typically, the p4 fetch command specifies a remote spec, and the DepotMap field in the remote spec specifies which files are to be fetched. The p4 fetch command may also specify a filespec argument to further restrict the files to be fetched. 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 fetch. In order to ensure that a partial changelist is not fetched, an appropriate filespec should be specified (for example, //...@change,#head). In addition to the file revisions and the changelists, the p4 fetch command also copies the archive content to this server.

The p4 fetch command also copies all integration records which describe integrations to the files being fetched. These integration records are adjusted in the current server to reflect the resulting changelist numbers and revision numbers of the current server. In order to fetch a set of files, you must have read access to those files in the remote server, and you must have write access to those same files in the local server; your local userid is used as the userid at the remote server and you must already be logged in to both servers prior to running the p4 fetch command.

By default, a server does not accept fetch requests from another server. In order to fetch from a server, an administrator of that server must enable fetching by setting server.allowpush to 1.

The p4 fetch command is atomic: either all the specified files are fetched, or none of them are fetched.

Files with the filetype modifiers +k, +l, or +S have some special considerations. Files of type +k have their digests cleared when fetched. This means certain cross-server merge conflicts are not detected. To re-generate the digests after the fetch, use the p4 verify command. When fetching files of type +l, the new files are added to the server even if the files are currently open by a pending changelist in this server. When fetching files of type +S, old archives which exceed the specified limit are not purged by the fetch command.

The p4 fetch command is not allowed if there are unsubmitted changes in this server; use p4 resubmit to resubmit those changes first, or discard the shelves with p4 shelve -d if they are not wanted.


p4 fetch automatically performs a p4 sync as part of its operations.


With no options specified p4 fetch fetches files from the remote server named origin.


Suppresses automatic sync of workspace to the head revision.

-m depth

Specifies that Perforce should perform a shallow fetch; only the last number of revisions specified in depth are fetched.


Performs correctness checks but doesn't fetch any files or changelists from the remote server. In particular, Perforce checks for conflicts between work that's been done in this server and working you're trying to fetch from the remote server. This tells you whether your personal server is up to date with the remote server.

-r remotespec

Specifies a remote spec containing the address of the remote server, and a file mapping which is to be used to re-map the files when they are fetched from the remote server. See also p4 remote.

-S stream

Specifies a particular stream to fetch. If you specify a stream you cannot also specify a file or files.


Specifies that conflicting changes should be unsubmitted. The -u option requires the -r option.


Specifies verbose mode, which provides diagnostics for debugging.


Specifies which files to fetch. 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



read on the remote server,
write on the local server.


p4 fetch -m 5 -r dev

Fetch the most recent 5 revisions of each file in the dev remote spec.

Related Commands

To push to a remote server

p4 push