Git branch tricks

At first Git might present a very different picture to a newbie, espcially if he/she has used other Source Code Management tools like Subversion or CVS. Most striking differnce is that there is no central repository for Git to operate. The repository is the .git directory created on a working tree.

This presented considerable confusion to me when I tried to learn Git. Finally I stumbled across the idea and took time to digest. There are pages explains how to make git emulate the central repository model. I have never used it and now I am much more comfortable with Git's model than central repository model.

Later when I started cloning (git-clone) and pulling (git-pull) from Linus' tree, I faced a very interesting problem. I created a branch by name experimental using the command,

$ git-branch experimental

I make my own modifications to this branch. At the same time, linux kernel goes forward by adding many patches. So I needed to pull the latest branch. But I did not switch to master branch by doing

$ git-checkout master

As a result, always my experiemental tree was merged, and not my master. So whenever I try to generate a patch by

$ git-diff  --patch-with-stat master experimental

I used to get all the differences applied to the main tree as well as the local patches I applied. So take care to do the git-checkout of the branch you wish to merge to.

Sometimes you may find git doing a diff of a number of files using the command diff --git a/path/to/file b/patch/to/file The reason is that git thinks there is a difference between them because of the time stamp stored and the time stamp of the file is different. So either do

$ git-status

or

$  git-update-index --refresh

This would get rid of the diff --git .... messages.

Editing your git commits

Say you need to make a change to a patch you've submitted for review. There are several ways to do this.

If the patch is your HEAD commit, you can run:

git commit --amend -v

That will allow you to edit the commit message. If you add changes to the staging area with `git add`, you can add those changes to your commit with the above command, along with your previously committed changes.

If you want to take the previous commit out of the git history, but leave the changes in your working tree, you can run:

git reset --mixed HEAD^

If you want to completely get rid of all your changes, and revert all files to their state before your commit, you can use the --hard flag instead of the --mixed flag. Use this flag with care!

Editing a patch in a series

Should you need to edit a patch that's not the head commit (say patch 1 of 3), you can use the "interactive" mode of git rebase. Simply pass git rebase the -i flag, followed by the commit ID of the patch before the patch you want to edit. For example, say we had this git log: