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
