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

P4 CLI Documentation | 2025.2

# p4 fetch

Copy files from a remote server into your local server.

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

## Syntax

    p4 [g-opts] fetch [-r remotespec] [-m depth] [-v -k] [-n | -t] [-Ox]
                      [-S stream | FileSpec[revSpec]
    p4 [g-opts] fetch [-r remotespec] [-v] [-n] [-Ox] -s shelf

Syntax and naming conventions

## Description

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

- the specified set of files, which can involve a specified revision range
- the changelists that submitted those files
- the files' attributes
- any fixes associated with the changelists, but only if the job that is linked by the fix is already present in the local server. If it is not, then the fix is not copied.
- all integration records that describe integrations to the files being fetched

A fetch is only allowed if the files being fetched fit cleanly into the server to which you’re currently connected, building cleanly on a shared common history.

The second form of the command copies a shelved changelist, rather than one or more submitted changelists, in which case conflicts do not arise. The result is a new shelved change in the local server.

If there are no conflicts, the files and their changelists become new submitted changelists in the local server. Conflict handling is configurable, using the `-t` option. If `-t` is not specified, and there are any conflicts or gaps, the fetch is rejected. The `-t` option specifies that the conflicting changelists should be relocated to the tangent depot, 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 the local 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 local 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 local server, none of the submit triggers are run in the local server.

If a particular revision of a file has been copied from ServerA to a local ServerB and ServerC, changing the attributes on that revision on the local 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 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 can also specify a filespec argument to further restrict the files to be fetched. The filespec argument can be one of the following:

- the name of a stream, such as -S dev
- a filename pattern, such as //stream/dev/..., //path1/..., or //...

You cannot not specify both a stream and a filename pattern in a single fetch command.

If you use a filespec argument to restrict the files to be fetched, the LastFetch: field will not be updated until you issue p4 fetch without a filespec argument .

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, only the matching files are included in the fetch. To ensure that a partial changelist is not fetched, an appropriate filespec should be specified (for example, `//...@change,#head`).

p4 fetch behaves differently if the remote spec’s `ArchiveLimits` field is set. This field regulates how many, if any, revisions of file archives are stored on the server you fetch to. For more information, see the section "Configure server to limit storage of archive revisions" in the "Fetching and Pushing" chapter of P4 Server Administration Documentation.

When `p4 fetch` copies integration records, they are adjusted in the local server to reflect the resulting changelist numbers and revision numbers of the local 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. To fetch from a server, an administrator of that server must enable fetching by setting server.allowfetch 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 the server. When fetching files of type `+S`, old archives which exceed the specified limit are not purged by the fetch command.

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

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

### Triggering on fetches

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

- The `push-submit` trigger can customize processing during the phase of the `p4 fetch` 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 fetch` 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 fetch` command.

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

## Options

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

Option | Description
--- | ---
`-k` | Suppresses automatic sync of workspace to the head revision.
`-m depth` | Specifies that P4 Server should perform a shallow fetch; only the last number of revisions specified in depth are fetched.
`-n` | Performs correctness checks but does not fetch any files or changelists from the remote server. In particular, P4 Server checks for conflicts between work that’s been done in the local server and work you are trying to fetch from the remote server. This tells you whether your personal server is up to date with the remote server.
`-Oc` | When set, the `p4 fetch` command outputs information about every changelist. The `-v` option must be set for this to take effect.
`-Of` | When set, the `p4 fetch` 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 fetch` 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 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`.
--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 fetched, 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.
`-t` | Specifies that conflicting changelists should be relocated to the tangent depot, automatically creating that depot if it does not exist. The relocated changes can then be resubmitted using `p4 resubmit`. If you don’t specify a remote server with the `-r` option, the remote server defaults to `origin`. p4 fetch -t requires `admin` permission.
`-S stream` | Specifies a particular stream to fetch. If you specify a stream you cannot also specify a file or files.
`-v` | Enables verbose mode, which provides diagnostics for debugging. With verbose mode enabled, you can refine and control the precise level of verbosity. Specifically, you can indicate whether you want information about: every changelist fetched (with the `-Oc` option) every file in every changelist fetched (with the `-Of` option) every integration of every file in every changelist fetched (with the `-Oi` option) You can specify any combination of these options, but must always include the `-O`. The default is to display information about every changelist.
File Spec[revSpec] | Specifies which files (and optionally which revisions) to fetch. If you specify 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 remote server, write on the local server.

## Examples

`p4 fetch -m 5 -r dev` | Fetch the most recent `5` revisions of each file in the `dev` remote spec.
`p4 fetch -r 1777-a //...@3,@6` | Fetch all files with revisions in the range of `3` to `6`

## Related commands

To push to a remote server | `p4 push`

Your search for returned results