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

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

Scenario 2: Combine two changes together 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 NNN+1)

  1. Unsubmit both changes:

    p4 unsubmit //…​@NNN
Change NNN+1 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 the second change.

  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. Get rid of the second change:

    p4 shelve -d -c NNN+1
p4 change -d -c NNN+1

    Alternatively, to get rid of the second change you could run p4 resubmit -i and choose “d”.