Embracing change is hard.  Accepting criticism on code you worked so hard to prepare for review can be hard on the ego.  But when you have additional work that is underway that depends on submissions undergoing review, it can also be a challenge to your organizational skills.  I’ve recently learned a trick about  git that makes this easier in the context of Open Stack development.

I have one change that I submitted for review.  My local branch for that review is called normalize as it deals with database normalization.   I have additional work that depends on that change, which is in a branch off of that called trusts.  Both changes modify the file keystone/identity/backends/sql.py  Dolph Matthews has been diligent in his responsibilities as a code reviewer and suggested some much needed changes to normalize.  I’ve made those changes, and reposted them for review.  Now I want to make sure that I don’t have to deal with any merge issues later on.  I want to make sure things are done as transparently as possible, but I want to let automation keep me from making mistakes.

So, first I make a “backup branch” which is really just the current state.

git checkout trusts
git checkout -b trusts trusts-orig

The commit I want  be seen with git log of the normalize branch:

[ayoung@ayoung530 keystone]$ git log normalize --oneline | head -1
1012bd4 normalize identity

I use an interactive rebase to specify the new state of the branch, by replacing the old commit hash with the new one.

git checkout trusts
git rebase -i HEAD~3

The old state

pick 904af11 Stop using cfg's internal implementation details
pick befa98e normalize identity
pick f3ec4ae Trusts sql backend definitions. sql upgrade scripts sql specific unit tests start of a service interface for API

I replace the hash on the second line with the one I got from git log before

pick 904af11 Stop using cfg's internal implementation details
pick 1012bd4 normalize identity
pick f3ec4ae Trusts sql backend definitions. sql upgrade scripts sql specific unit tests start of a service interface for API

Once I close the editor, my trusts branch reflects the new state of development. If there are any conflicts, I will be asked to modify my commit, but in this case, there aren’t.

Once my normalize review gets accepted, and assuming there are no other reviews that get merged in the meantime, when the time comes to synchronize with origin/master, there are no code changes made to my tree by the rebase.

UPDATE:
Simo Sorce pointed out that I was much better off if I use:

git checkout normalize
git fetch
git rebase origin/master
git checkout trusts
git rebase -i normalize

This will allow me to remove the commit prior to the rebasing.

From Simo:

what it says is rebase the current branch on top of the other so it picks *any* patch not in the other including patches that bear the same name but are not the same change. It just so happen they are normally the ‘old’ versions so you can simply remove them. So a prerequisite is to usually rebase both branches on master so that they share the same history, but it is sufficient if you rebase only ‘normalize’ on master. By rebasing [trusts] on top of normalize you implicitly also rebase on master