Rewriting History

Perforce allows you rewrite the history of the changes in your server. There are two reasons why you would want to rewrite history:

  1. To resolve conflicts between a local server’s file history and a remote server’s file history that arise when fetching or pushing.
  2. To revise local work: correcting mistakes, clarifying intent, and streamlining the local commit history by consolidating intermediate changes.

Resolve conflicts by rewriting local history

If there are conflicts between a local server’s file history and a remote 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 -u. This does the following:

  1. Unsubmits and creates a shelved changelist for the current local changes.
  2. Fetches the remote work from the shared server.

The user then runs 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 will fail and you will 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 -u, which unsubmits and shelves User A’s revision 5, 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.