Rewrite history to revise local work

This section examines two scenarios in which you might want to revise local work by rewriting history.

Scenario 1: You forgot to map a file

Suppose you wrote a new class in C++: src/module/UserUtils.cpp and it uses the header file inc/UserUtils.h. You then issue this command: 

$ p4 submit UserUtils.cpp

Your build script complains about the missing include file UserUtils.h. To fix this, you would issue the following commands: 

$ p4 unsubmit UserUtils.cpp
$ p4 resubmit -e

Now UserUtils.cpp is open. You would then run: 

$ p4 add -c NNN UserUtils.h
$ p4 resubmit -Re

Where NNN is a changelist number.

Now the permanent history shows that your change contains both UserUtils.cpp and UserUtils.h.

Scenario 2: Combine two changes to remove "noise" from the history

Suppose you add a feature in change NNN. A reviewer finds a problem with it, so you make another change to fix the problem. Then you realize that the second change is just adding noise to the history.

To fix this, you would do the following:

(We assume your first change is NNN and your second change is MMM)

  1. Unsubmit both changes:

    $ p4 unsubmit //...@NNN,@MMM
Change MMM unsubmitted and shelved
Change NNN unsubmitted and shelved

  2. Start the partially-interactive resubmit process:

    $ p4 resubmit -e

    Now change NNN is open for edit.

  3. Make the change you originally made in changelist NNN.

  4. Update the change description:

    $ p4 change NNN

  5. Resume the resubmit process:

    $ p4 resubmit -Re

    Now the second change is open for edit but you don’t need it. You can demonstrate this to yourself by running p4 resolve, p4 diff, and p4 revert -a to see that nothing is changed by the second change.

  6. Delete the second change:

    $ p4 shelve -d -c MMM
$ p4 change -d -c MMM

    Alternatively, to delete the second change you could run p4 resubmit -i and choose d.