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

P4 Distributed Versioning Documentation | 2025.1

# Resolve conflicts by rewriting local history

If there are conflicts between a personal server’s file history and a shared server’s file history, a fetch will fail and report the conflict. This happens when you’ve changed some files in your personal server at the same time that someone else has changed those files in the shared server.

In this situation, you run `p4 fetch -t`. This does the following:

1. Relocates conflicting changelists to the tangent depot.
2. Fetches the remote work from the shared server.

You then run `p4 resubmit -m` to resubmit and automatically merge the conflicting local changes.

If your conflict(s) involved the same line or lines then `p4 resubmit -m` fails and you need to:

1. Run `p4 resolve` to resolve the conflict(s).
2. Run `p4 resubmit -Rm` to resume the resubmit.

Consider the following example:

1. User A clones from a shared server, bringing down revision 4 of `//stream/main/foo.c` (`//stream/main/foo.c#4`).
2. User A edits `foo.c` and then submits it, creating `//stream/main/foo.c#5`.
3. In the meantime, User B, has made two edits to `//stream/main/foo.c` and pushed them to the shared server. The shared server is now at revision 6 (`//stream/main/foo.c#6`).
4. User A attempts to push their change to the shared server, but the push fails because the file version history doesn’t fit.
5. User A must now run `fetch -t`, which relocates User A’s revision 5 to the tangent depot, and fetches revisions 5 and 6 from the shared server.
6. User A now runs `resubmit -m`. User A’s change, originally numbered 5, is submitted as revision 7.
7. User A pushes their change to the shared server. The push succeeds.

Your search for returned results