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

P4 CLI Documentation | 2025.2

# p4 flush

Update the have list The list of file revisions most recently synced from the depot into the workspace. In other words, the list of files that the client workspace has. of a client workspace without copying any files.

## Syntax

    p4 [g-opts] flush [-f -L -n -q] [FileSpec[revSpec]]

Syntax and naming conventions

## Description

p4 flush can cause commands to behave in unexpected ways, so use it only when the situation is appropriate. See the two Examples.

The `p4 flush` command performs only Step 2 of `p4 sync` `FileSpec` two-step operation:

Step 1: The file revisions in the FileSpec are copied from the depot to the client workspace.

Step 2: The have list of the client workspace is updated to reflect the new client workspace contents.

Under most circumstances, the have list of a client workspace reflects the contents of that workspace. However, if the workspace’s contents do not match the have list, `p4 flush` might make the have list match the actual contents. Because `p4 flush` performs no actual file transfers, this command is much faster than the alternative of running `p4 sync`.

## Options

Option | Description
--- | ---
`-f` | Force the flush. P4 Server performs the flush even if the client workspace already has the file at the specified revision.
`-L` | For scripting purposes, perform the flush on a list of valid file arguments in full depot syntax with a valid revision number.
`-n` | Display what the results of the flush would be without actually performing the flush. This preview can help you avoid unwanted surprises.
`-q` | Quiet operation: suppress normal output messages. Messages regarding errors or exceptional conditions are not suppressed.
`g-opts` | See Global options.

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required | Command Alias
--- | --- | --- | ---
Yes | Yes | `read` | `p4 sync -k`.

- Because `p4 flush` updates the have list without copying files, and `p4 sync -f` updates the client workspace to match the have list, `p4 flush files` followed by `p4 sync -f` is almost equivalent to the `p4 sync` `files` command. This means that a bad flush can be partially fixed by following it with a `p4 sync -f` of the same file revisions that were originally flushed. However, this is not a complete fix because any file revisions that were deleted from the have list by `p4 flush` remain in the client workspace even after `p4 sync -f` has run. In such a case, manually remove deleted file revisions from the client workspace.

## Examples

- Ten users at the same site need to set up new, identical client workspaces from the same depot at a remote location over a slow link. Typically, each user would run identical `p4 sync` commands, which means the command would be run a total of ten times. However, if bandwidth is limited, this process can save time:

  1. One user runs `p4 sync` `files` from the client workspace `firstworkspace`.
  2. The other users copy the newly-synced files from the first user’s client workspace into their own client workspaces using their local OS file-copying commands.

  3. The other users run `p4 flush files@firstworkspace`, which quickly brings their client workspaces' have lists into sync with the files copied into the client workspaces in Step 2. Because `p4 flush` moves no files across the slow link, this is much faster then running the same `p4 sync` command ten separate times.

- Joe has a client workspace called `joe` that has a `Root:` of
  `/usr/joe/project1/subproj`
  and a `View:` of
  `//depot/joe/proj1/subproj/... //joe/...`
  Joe decides that all the files under `/usr/joe/project1` need to be included in the workspace, and uses `p4 client` to change the `Root:` to `/usr/joe/project1`
  and the `View:` to `//depot/joe/proj1/... //joe/...`.

  This keeps his current client workspace files in the same place while extending the scope of the workspace to include other files. But when Joe runs his next `p4 sync`, he is surprised to see that P4 Server deletes every non-open file in the client workspace and replaces it with an identical copy of the same file!

  P4 Server behaves this way because:

  - the have list describes each file’s location relative to the client root
  - the physical location of each file is determined when each P4 Server command is run.

  Therefore:

  - P4 Server thinks that each file has been relocated
  - p4 sync deletes the file from its "old" location and copies it into its "new" location

  The efficient solution in this case is to use `p4 flush #have` to update the client workspace’s have list to reflect the "new" locations of the files without actually copying any files.

  ## Related commands

  p4 flush is an alias for `p4 sync` -k | `p4 sync` -k
  To copy files from the depot to the client workspace | `p4 sync`
  To bring the client workspace in sync with the have list after a bad `p4 flush` | `p4 sync` -f

Your search for returned results