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

P4 CLI Reference | 2025.1

# p4 integrated

Show integrations that have been submitted.

## Syntax

    p4 [g-opts] integrated [-b branchname [-r]] [-s change | -m max] [--into-only] file ...

Syntax conventions

## Description

The `p4 integrated` command shows the integration history of the selected files, and uses this format:

``file`#`revision-range` - `integrate-action``partner-file`#`revision-range``

where:

- file is the file argument provided to p4 integrated
- partner-file is the file it was integrated from or into

- integrate-action describes what the user did during the `p4 resolve` process, and is one of the following:

  Integrate Action | Resolve Process
  --- | ---
  `add into` | file was integrated into previously nonexistent `partner-file`, and `partner-file` was reopened for `add` before submission.
  `add from` | file was integrated from a deleted `partner-file`, and `partner-file` was reopened for `add` (that is, someone restored a deleted file by syncing back to a pre-deleted revision and adding the file).
  `branch from` | file did not previously exist; it was created as a copy of `partner-file`.
  `branch into` | partner-file did not previously exist; it was created as a copy of `file`.
  `merge from` | file was integrated from `partner-file`, accepting `merge`.
  `merge into` | file was integrated into `partner-file`, accepting `merge`.
  `moved from` | file was integrated from `partner-file`, accepting `theirs` and deleting the original.
  `moved into` | file was integrated into `partner-file`, accepting `theirs` and creating `partner-file` if it did not previously exist.
  `copy from` | file was integrated from `partner-file`, accepting `theirs`.
  `copy into` | file was integrated into `partner-file`, accepting `theirs`.
  `ignored` | file was integrated from `partner-file`, accepting `yours`.
  `ignored by` | file was integrated into `partner-file`, accepting `yours`.
  `delete from` | file was integrated from `partner-file`, and `partner-file` had been previously deleted.
  `delete into` | file was integrated into `partner-file`, and `file` had been previously deleted.
  `edit from` | file was integrated from `partner-file`, and `file` was edited within the `p4 resolve` process. This allows you to determine whether the change should ever be integrated back; automated changes (`merge from`) needn’t be, but original user edits (`edit from`) performed during the resolve should be.
  `edit into` | file was integrated into `partner-file`, and `partner-file` was reopened for `edit` before submission.
  undid | the resulting revision has "undid" the edited changes (content and history) from the previously submitted revision(s). Revision #4 "undid" Revision #3: This is one of the two actions of p4 undo.
  undone by | the previous revision(s) have been "undone by" the resulting revision, known as the "undone" revision. Revision #4 was "undone" by Revision #3: This is one of the two actions of p4 undo.

Add w/ Edit, Merge w/ Edit and Undone w/Edit are possible, but best practice is only one action per changelist.

If a file `toFile` was ever integrated from a file `fromFile`, and both `toFile` and `fromFile` match the `p4 integrated` `filepattern` argument, each integrated action is listed twice in the `p4 integrated` output: once in its `from` form, and once in its `into` form, as described above.

If the optional `-b branch` option is used, only files integrated from the source to target files in the branch view are shown.

If the optional `-r` option is provided, the mappings in the branch view are reversed. This option requires the use of the `-b branch` option.

To make it easier to show where a change has been integrated to, consider using the -s and --into-only options.

## Options

`-b branchname` | Lists only files integrated from the source to target files in the branch view. Qualified files are listed, even if they were integrated without using the branch view.
`-r` | Reverses the mappings in the branch view, swapping the target files and source files. The `-b` branch flag is required.
-s change | Lists the integrations from the specified change forward toward the present.
`-m max` | Lists only the `max` most recent integrations. The output is sorted by descending change number. This option cannot be used with `-s` option.
--into-only | Lists only integrations from this path into other paths, not integrations from other paths into this one, or changes ignored by the target path.
`g-opts` | See Global options.

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
No | No | `list`

- When using tagged output with `p4 integrated` be warned that the `toFile` and `fromFile` values will be the opposite of how they are presented in the non-tagged output. The following example shows how the output varies:

      p4 integrated //depot/main/revisions.h
      //depot/main/revisions.h#1 - add into //depot/dev/revisions.h#1

      p4 -ztag integrated //depot/main/revisions.h
      ... toFile //depot/main/revisions.h
      ... fromFile //depot/dev/revisions.h
      ... startToRev #none
      ... endToRev #1
      ... startFromRev #none
      ... endFromRev #1
      ... how add into
      ... change 12345

  See Global options for information on how to enable tagged output.

## Related commands

To see a list of integrations that have not yet been resolved | `p4 resolve` -n
To view a list of integrations that have been resolved but not yet submitted | `p4 resolved`
To perform an integration | `p4 integrate`
To view the actions taken for all revisions of a particular file (including all the files from which that particular file was integrated) | `p4 filelog [-i] file`

Your search for returned results