You are currently browsing the monthly archive for April 2008.

“What? I already fixed this bug! Why is it still happening?” If you don’t have a good test suite or you don’t run it regularly, finding these sorts of regressions can be difficult. Because git makes it really easy to jump to other commits (branches or history), it is very easy to narrow down what commit(s) caused the regression. git bisect helps you do that.
Read the rest of this entry »

Imagine you’re an integrator (someone who takes a lot of changes from other people and merges them) and you often merge other people’s branches, resolve conflicts, and then find bugs in the branch. Wouldn’t it be great if git could remember your conflict resolutions and replay them next time you try to merge? That’s what git rerere is for!
Read the rest of this entry »

What do you do when you have two commits in the past that you want to re-arrange? or combine? or completely obliterate? What about after you’ve created patches, emailed them to a maintainer, and that maintainer has accepted some of them into the official repo? What if you realize that your topic branch actually has two topics in it? These are all jobs for git rebase.
Read the rest of this entry »

A topic that I plan to cover is the git index but some people already have. These two links describe nearly the same thing except one uses git add -i and the other git add -p. Git’s index is a great staging area to use before putting commits into the repo.

Have you ever committed something, tried to git rebase, and everything went horribly horribly wrong? Or accidentally git reset --hard HEAD^ when you meant to git reset HEAD^? Have no fear, git reflog is here!
Read the rest of this entry »

Some people don’t seem to understand how git gc fits in with the git object database or even how the git object database works. Here’s a description of the git object database and why running git gc helps performance.

Read the rest of this entry »