Skip to content

Boaz's secret recipe in using git

phdeniel edited this page Jan 26, 2012 · 1 revision

you do not merge back ever! The flow of code is only one way. From my branch into Ganesha branch. Never the other way around.

Once your code is in. You reset to some stable point in Ganesha that includes your work. Say Linus pulled my work into post 3.2 merge window. My next base will be 3.3-rc1. I will never base my tree on some random point of Linus tree.

So here is the flow of work.

I. Reset to a stable base

say you are at the xiv branch in your tree

[]$ git remote update This will fetch Ganesha tree all branches.

[]$ git status This to make sure your tree is clean and you don't have any local modifications.

[]$ git reset --merge <LATEST_GANESHA_NEXT_TAG>

As I said don't reset to a random point in next tree. Reset to the latest stable tag, as marked by Phillip.

(The --merge flag means, make HEAD index and checkout as the specified commit like --hard. But do not allow local changes. So it is a safe practice to do "git reset --merge" and not "git reset --hard")

An alternative to the above could be: []$ git branch -f xiv <LATEST_GANESHA_NEXT_TAG_X> []$ git checkout xiv But that will work only if xiv branch is not the one already checked out.

At this point xiv branch == LATEST_GANESHA_NEXT_TAG_X

II. edit make changes and commit

now you are committing a series of patches which are all cleanly based on LATEST_GANESHA_NEXT_TAG_X

If a short time has passed and not much as changed in next then you can just send the pull request.

III. need to rebase

Say that by now next is at LATEST_GANESHA_NEXT_TAG_(X+t) and there are anticipated conflicts. (You should actually test for that see how below.) So in this case you will need to rebase. []$ git remote update This will fetch Ganesha tree

[]$ git rebase --onto LATEST_GANESHA_NEXT_TAG_(X+t) LATEST_GANESHA_NEXT_TAG_X

See how nice? We based our work on a tagged point so it is easy to specify to rebase what is the BASE point.

Now the tree is clean ontop of LATEST_GANESHA_NEXT_TAG_(X+t) and you can send the pull-request.

IV. How to make sure my branch is merge-able

[]$ git remote update []$ git checkout origin/next

origin above is the default remote name of the tree you "git cloned". Assuming Ganesha. Otherwise it's the name you gave to the git remote add command

[]$ git merge xiv If all is well then good. If there are conflicts goto [3. need to rebase] (don't forget to "git checkout xiv" before [3])

V. Ready for the pull

So you now have a clean patchset ontop of a stable TAG that does not conflict with latest next. You can send the pull request from github or by running: []$ git pull-request LATEST_GANESHA_NEXT_TAG_Y <url of git:// tree> xiv And send the output by mail.

Once your work is pulled you can now GOTO [1. Reset to a stable base]

VI. What if I had a long standing work based on some historical HEAD

It might be that you started a long topic branch say locks-up-call. You based your work like in [1] lets call it LOCKS_UC_BASE. You worked and worked. Now you don't want this branch to get to much out of sync with mainline so from time to time when you see that mainline has work that might conflict with yours, but that you must incorporate. Perhaps a new API that you must address and so on. And you are in a point in your project that is calm. Choose your timing right. Then do like "III. need to rebase".

Once you are done with your project. You have made the last [3] and verified [4] for the pull you want it to be the xiv branch. So that's simple:

[]$ git branch -f xiv locks-up-call make xiv == locks-up-call

Now send the pull-request.

So to summarize. Every piece of work starts with a git reset --merge <SOME_STABLE_POINT> and ends with a pull-request. And goto NEW_STABLE_POINT