[Insight-developers] SimpleITK: revert topic merged into next

[Brad King]

On Wed, Dec 14, 2011 at 12:43 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> I have been unsuccessful with using git revert as per the instructions
> here  2.7 Abandoning a Topic.

I updated the instructions

   http://public.kitware.com/Wiki/Git/Workflow/Stage#Abandoning_a_Topic

with a note about merges in the topic.

 > I am tempted to just to a reset --hard
> origin/master ( or the most recent master first parent) and commit that as
> reverting the topic.

That will just move your local topic pointer over to be the same as master.
You need to fix the *content* of your topic without rewriting its history.

 > Is this the best way to create a commit that reverts
> all the changes in the topic, before merging back into next?

First merge master into the topic:

  $ git checkout SIMPLEITK-121_NoITKInclude
  $ git fetch origin master:master
  $ git merge master

Then commit a change that reverts everything to be equal to master:

  $ rm .git/index
  $ git read-tree --reset -u master
  $ git commit -m "Revert topic 'SIMPLEITK-121_NoITKInclude'"

After this you'll need to clean up your work tree because removing
.git/index hid some stuff from Git:

  $ git clean -f -d -- Code

Then push the topic and merge to next as usual following the above-linked
instructions.

Note that the above will revert *everything* in the topic that has not
already been merged to master, including other topics that have been
merged into the reverted topic.  In this particular case the above
instructions will revert both topics you asked about since one has
been merged into the other.  I don't see any other topics in it that
have not already made it to master, so you should be okay.

I tested the above and ended up with a next that has content identical
to the one topic that remains in it after this reversion.  This is
expected and correct.

Another option is to reset next back to master and throw out its old
history.  Then rebase all the active topics on master and merge them
to next again.  Some projects do this occasionally to keep the history
of next minimal.  In our case it requires some extra work to fix up
server-side hooks that prevent next from being merged into master.
It is probably too heavy-handed given how little you actually have
in next that is not in master right now.

-Brad K