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

P4 CLI Documentation | 2026.1

# p4 resolve

Resolve conflicts between file revision, or resolve a stream spec conflict.

## Syntax

    p4 [g-opts] resolve [-a options] [-A options] [-d options] [-f  -n  -N  -o  -t  -v]
                        [-c change] [file ...]
    p4 resolve -So [ -af -am -as -at -ay -n -o ]

Syntax and naming conventions

## Description for files

Use `p4 resolve` to combine the contents of two files or file revisions into a single file revision in your workspace.

When `p4 resolve` is run with no file arguments, it operates on all files in the client workspace that have been scheduled for resolve. (The phrase "schedule for resolve" means that file resolution can be deferred until the user wants to prepare the file for submission.)

Two situations require the use of `p4 resolve` before a file can be submitted:

- When a simple conflict exists: the revision of a file last synced to the client workspace is not the head revision at the time of the submit.

  For example,

  1. Alice does a `p4 sync` followed by a `p4 edit` of file `file.c`, and Bob does the same thing.

  2. Alice does a `p4 submit` of `file.c`, and then Bob tries to submit `file.c`.

  3. Bob’s submit fails because if his version of `file.c` were to be accepted into the depot, Alice’s changes to `file.c` would no longer be visible. Bob must resolve the conflict before he can submit the file.

- When `p4 integrate` has been used to schedule the integration of changes from one file (or branch) to another.

Resolving a simple file conflict involves multiple revisions of a single file, but resolving for integration involves combining two separate files. In either case,

p4 resolve allows the user to ... | ... if the file is text | ... if the file is binary
--- | --- | ---
Use the file in the client workspace instead of the file in the depo | Yes | Yes
Overwrite the file in the client workspace with the file in the depot | Yes | Yes
Merge changes from both the depot revision and the client workspace revision into a single file | Yes | No

The output of `p4 resolve` is diagnostic. Files are either resolved against ("vs") another file, copied, merged, edited, branched, added, deleted, moved, or ignored with respect to other files. The actual work performed by `p4 resolve` is reflected by the changes it makes to files in the client workspace.

p4 resolve is not supported for files with propagating attributes from an edge server A server that is part of a commit-edge environment that can independently support work in progress for locally-bound clients, thereby reducing the load on the commit server..

To learn how to work with a range of revisions, see Revision ranges.

### Revisions Used to Detect Conflicts

The `p4 resolve` dialog refers to four file revisions whose meaning depends on whether or not the resolution fixes a simple file conflict or is resolving for integration:

Term | Meaning when Resolving Conflicts | Meaning when Resolving for Integration
--- | --- | ---
yours | The revision of the file in the client workspace | The file to which changes are being propagated (in integration terminology, this is the target file). Changes are made to the version of this file in the client workspace, and this file is later submitted to the depot.
theirs | The head revision of the file in the depot. | The file revision in the depot from which changes are being propagated (in integration terminology, this is the source file). This file is not changed in the depot or the client workspace.
base | The file revision synced to the client workspace before it was opened for edit. | The base 1. For files: The file revision that contains the most common edits or changes among the file revisions in the source file and target file paths. 2. For checked out streams: The public 'have' version from which the checked out version is derived. See also 'have list'. revision can be in either the source path or the target path.
merge | A file version generated by P4 Server from yours, theirs, and base. The user can edit this revision during the resolve process if the file is a text file.

### Resolve Options and Details

The interactive `p4 resolve` dialog presents the following options. Note that the dialog options are not the same as the command line options.

Dialog Option | Short Meaning | What it Does | Available by Default for Binary Files?
--- | --- | --- | ---
`e` | edit merged | Edit the preliminary merge file generated by P4 Server. | no
`ey` | edit yours | Edit the revision of the file currently in the workspace. | yes
`et` | edit theirs | Edit the revision in the depot with which the workspace revision conflicts (usually the head revision). This edit is read-only. | yes
`dy` | diff yours | Show diffs between yours and base. | no
`dt` | diff theirs | Show diffs between theirs and base. | no
`dm` | diff merge | Show diffs between merge and base. | no
`d` | diff | Show diffs between merge and yours. | yes
`m` | merge | Invoke the command: P4MERGE base theirs yours merge To use this option, you must set the environment variable `P4MERGE` to the name of a third-party program that merges the first three files and writes the fourth as a result. This command has no effect if `P4MERGE` is not set. | no
`?` | help | Display help for `p4 resolve`. | yes
`s` | skip | Don’t perform the resolve right now. | yes
`ay` | accept yours | Accept yours, ignoring changes that might have been made in theirs. | yes
`at` | accept theirs | Accept theirs into the client workspace as the resolved revision. The revision (yours) that was in the client workspace is overwritten. When resolving simple conflicts, this option is identical to performing `p4 revert` on the client workspace file. When resolving for integrate, this copies the source file to the target file. | yes
`am` | accept merge | Accept the merged file into the client workspace as the resolved revision without any modification. The revision (yours) originally in the client workspace is overwritten. Manually accepting a merge resolve (`p4 resolve` and selecting `am`) is different from automatic merge resolve (`p4 resolve -am`). When manually accepting a merge resolve, the user makes a conscious choice. `p4 resolve -am` automates the choice to accept yours, accept theirs, or accept merge, depending on the three-way merge differences. If additions and deletions are in: only the target file, the target differences are kept (the same as a manual accept yours) only the source file, the source differences are kept (the same as a manual accept theirs) both the source and target files with no conflicts, the merged result is kept (the same as a manual accept merged) both the source and the target files with conflicts, the merged result is skipped (the same as a manual skip) | no
`ae` | accept edit | If you edited the file (that is, by selecting “e” from the `p4 resolve` dialog), accept the edited version into the client workspace. The revision (yours) originally in the client workspace is overwritten. | no
`a` | accept | Keep P4 Server’s recommended result: if theirs is identical to base, accept yours; if yours is identical to base, accept theirs; if yours and theirs are different from base, and there are no conflicts between yours and theirs; accept merge; otherwise, there are conflicts between yours and theirs, so skip this file | no

Resolution of a file is completed when any of the `accept` dialog options are chosen. To resolve the file later or to revert the change, `skip` the file.

To help decide which option to choose, counts of four types of changes that have been made to the file revisions are displayed by `p4 resolve`:

    Diff Chunks: 2 yours + 3 theirs + 5 both + 7 conflicting

The meanings of these values are:

Count | Meaning
--- | ---
`n yours` | `n` non-conflicting segments of yours are different than base 1. For files: The file revision that contains the most common edits or changes among the file revisions in the source file and target file paths. 2. For checked out streams: The public 'have' version from which the checked out version is derived. See also 'have list'..
`n theirs` | `n` non-conflicting segments of theirs are different than base.
`n both` | `n` non-conflicting segments appear identically in both theirs and yours, but are different from base.
`n conflicting` | `n` segments of theirs and yours are different from base and different from each other.

If there are no conflicting chunks, it is often safe to accept the generated merge file, because P4 Server will substitute all the changes from yours and theirs into base.

If there are conflicting chunks, the merge file must be edited. In this case, P4 Server will include the conflicting yours, theirs, and base text in the merge file. You can choose which version of the chunk you want to keep.

The different text is clearly delineated with file markers:

    >>>> ORIGINAL VERSION file
    #n
    <text>==== THEIR VERSION file
    #m
    <text>==== YOUR VERSION file
    <text><<<<

Choose the text you want to keep. Delete the conflicting chunks and all the difference markers.

### Non-Content-Related Resolves

You can also resolve other types of conflicts between related files: filetype, deletion, branching, and attributes, as well as moves and renames. See Resolve conflicts.

To constrain the process to one type of resolve, use the `-A` option.

Option | What is Resolved
--- | ---
`-Aa` | Resolve attributes set by `p4 attribute`.
`-Ab` | Integrations where the source is edited and the target is deleted.
`-Ac` | Resolve file content changes as well as actions.
`-Ad` | Integrations where the source is deleted and target is edited.
`-Am` | Renames and moves.
`-At` | Filetype changes.
`-AQ` | Charset changes.

Each type of resolve is handled separately. For example, if a file has both a filetype conflict and a content conflict, you are prompted separately to specify how each is handled. To avoid file-by-file prompting when the desired outcome is the same for all resolves, include the `-at` or `-ay` option following the `-A` option. The following example illustrates how prompting is handled for different resolves.

Copy

    Merging //depot/rel/fileb#1
    Diff chunks: 1 yours + 0 theirs + 0 both + 0 conflicting
    Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) ay: m
    //depot/main/filez - resolve skipped.
    Resolving move to //depot/main/fileb
    Filename resolve:
    at: //depot/main/fileb
    ay: //depot/main/filez

## Description for a stream spec conflict

Suppose that two clients, A and B, both edit the same stream spec. Client A opens the stream spec for editing. Client B either opens the stream spec for editing and submits, or edits globally and saves changes to the stream spec. Client A’s open stream spec is now in a conflict condition.

p4 submit [-Si|-So|-Sx] detects the conflict condition and prevents the opened stream from being submitted.

p4 resolve –So [ -af -am -as -at -ay -n -o ] allows for a resolve preview, or resolves by merging the changes. The resolve can ignore either the changes that are theirs or yours.

## Options for files

Option | Description
--- | ---
`-a`options`` `-as` `-am` `-af` `-at` `-ay` | Skip the resolution dialog, and resolve the files automatically :
-as | 'Safe' resolve; skip files that need merging. If either yours or theirs is different from base, accept that revision. If changes are identical, accept theirs. If both yours and theirs are different from base, skip this file. However, if both yours and theirs are different from base, but there is nothing only in theirs and no conflicting, keep yours
`-am` | Resolve by merging; skip files with conflicts. Causes the workspace file to be replaced with the result of merging theirs with yours. If the merge detected conflicts, the file is left untouched and unresolved.
`-af` | Force acceptance of merged files with conflicts. Causes the workspace file to be replaced with the result of merging theirs with yours, even if there were conflicts. This can leave conflict markers in workspace files.
`-at` | Force acceptance of theirs; overwrites yours. Resolves all files by copying theirs into yours. It should be used with care, as it overwrites any changes made to the file in the client workspace.
`-ay` | Force acceptance of yours; ignores theirs. Resolves all files by accepting yours and ignoring theirs. It preserves the content of workspace files.
When a file has been deleted in branch A and not in branch B, merging B into A results in a conflict, and a subsequent `p4 resolve -as` does not resolve the conflict. However, if the dm.resolve.ignoredeleted configurable is set to `1`, `p4 resolve -as` resolves the conflict by honoring the deletion in branch A.
`-A`options`` `-Aa` `-Ab` `-Ac` `-Ad` `-At` `-Am` | Action resolves that limit what to resolve: -Aa: Resolve attributes set by the `p4 attribute` command. -Ab: Resolve file branching, that is, integrations where the source is edited and the target is deleted. -Ac: Resolve file content changes. -Ad: Integrations where the source is deleted and the target is deleted. -At: Filetype changes. -Am: Move and renames. See also Non-Content-Related Resolves.
`-d`option`` | When merging files, ignore specified differences in whitespace or line-ending convention. (If you use these options, and the files differ by whitespace only, `p4 resolve` uses the text in the workspace file.) -db: Ignore whitespace-only changes (for instance, a tab replaced by eight spaces) -dw: Ignore whitespace altogether (for instance, deletion of tabs or other whitespace) -dl: Ignore differences in line-ending convention
`-f` | Allow already resolved, but not yet submitted, files to be resolved again. The content of the target (yours) file being re-resolved is the result of the previous resolve, not the content of the original file. To preserve the option of using the original file, revert the resolved file. See the Examples for files.
`-n` | List the files that need resolving without actually performing the resolve.
`-N` | Preview the operation with additional information about any non-content resolve actions that are scheduled.
`-o` | Output the base file name and revision to be used during the resolve.
`-t` | Force a three-way merge, even on binary (non-text) files. This allows you to inspect diffs between files of any type, and lets you merge non-text files if `P4MERGE` is set to a utility that can do such a thing.
`-v` | Include conflict markers in the file for all changes between yours and base, and between theirs and base. Normally, conflict markers are included only when yours and theirs conflict.
`-c change` | Limit the scope of the resolve operation to the files opened in the specified changelist number.
`g-opts` | See Global options.

## Options for streams

Option | Description
--- | ---
-So | Resolves only opened stream spec conflicts. The options are: p4 resolve –So [ -af -am -as -at -ay -n -N -o ] `p4 resolve -So` is an alias for the `p4 stream resolve` command.
``-af`` | Force the combination of text fields with conflicts.
`-am` | Resolve by merging. Skip fields with conflicts.
`-as` | Safe resolve. Skip fields that need merging. If either yours or theirs is different from base, accept that revision. If changes are identical, accept theirs. If both yours and theirs are different from base, skip this file. However, if both yours and theirs are different from base, but there is nothing only in theirs and no conflicting, keep yours.
`-at` | Force acceptance of theirs. Overwrite yours.
-ay | Force acceptance of yours. Ignore theirs.
-n | Preview which fields require resolve.
-o | Output the base change (the have change) used for the merge.

## Usage notes

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

p4 resolve works only with files that have been scheduled for resolve.

Three operations schedule files for resolution:

Option | Description
--- | ---
Integrating the file with `p4 integrate` or `p4 merge`. | When scheduling files for resolve, `p4 integrate` selects the closest common ancestor as the base. The `p4 merge` command selects the revision with the most edits in common with the source and target.
Submitting an open file that was synced from a revision other then the current head revision. | The submit fails, and the file is scheduled for resolve.
Running `p4 sync` instead of running `p4 submit` on the open file. | Nothing is copied into the client workspace. Instead, the file is scheduled for resolve. The benefit of scheduling files for resolve with `p4 sync` instead of a failed submit is that the submit will not fail.

If translation errors occur during integrations between `text` and `unicode` files, the most likely cause is the presence of non-ASCII characters in the `text` file. Either remove the non-ASCII characters from the file before integration, or set `P4CHARSET` to `utf8` and attempt the merge again.

## Examples for files

Re-resolving a file using the `-f` flag is not necessarily equivalent to reverting the resolved file and performing the resolve again. Suppose that in the initial resolve, you used the accept theirs (`-at`) option:

    p4 resolve -at
    /Users/bruno/dir8/dir2/fileA.txt - vs //depot/dir6/dir2/fileA.txt#2
    //bruno/dir8/dir2/fileA.txt - copy from //depot/dir6/dir2/fileA.txt

But for re-resolving, you instead use the accept yours (`-ay`) option:

    p4 resolve -f -ay
    /Users/bruno/dir8/dir2/fileA.txt - vs //depot/dir6/dir2/fileA.txt#2
    //bruno/dir8/dir2/fileA.txt - copy from //depot/dir6/dir2/fileA.txt

In this case, the depot version is copied into the client workspace instead of the depot version being ignored.

## Example for a stream conflict

A conflict prevents an open stream edit from being submitted:

p4 -c ws0 submit -d "Conflict detected?" -So
Submitting change 5.
Stream //root/main is out of date; run 'p4 stream resolve'.

Stream resolve preview:

p4 -c ws0 resolve -So -n
//root/main Paths - resolving //root/main@4

Stream resolve with a conflict merge scenario, the attempt with –am fails but the attempt with –af succeeds:

p4 -c ws0 resolve -So -am

//root/main Paths - skipped //root/main@4
p4 -c ws0 resolve -So -af
//root/main Paths - combined with //root/main@4

The Paths: field now looks like:

    Paths:
      share a # open
      share c # open
      share b # open

## Related commands

To view a list of resolved but unsubmitted files | `p4 resolved`
To schedule the propagation of changes between two separate files | `p4 integrate`
To submit a set of changed files to the depot | `p4 submit`
To copy a file to the client workspace, or schedule an open file for resolve | `p4 sync`

Your search for returned results