ReadyState4

or better known as “staging patches”.

So you created some new functionality in a file but you have a lot of other code you’re not quite ready to commit yet. Answer: git add -p . It will interactively go though modified sections of your file asking if you want to “stage this hunk”. Answer y for yes, n for no, q for stop, then commit as usual. You can even split hunks if you want to get more fine-grained.

For more details check out this page.

In a previous project I used a bash script in conjunction with a git hook to concatenate all my js files and increment build numbers in html file references (cache-kill) after every commit. This was convenient at first, but quickly got annoying as I wasn’t always committing js file changes. I eventually opted to just call the script manually before any deployment to qa or production, thinking I would automate it again one day to only be called when JS files were changed (git hooks probably provide this info).

Today I read up on make. I’ve always used make in the past to build versions of a program for my system but never how it actually worked. When ran, it essentially reads in a list of dependencies, and if the source files have modification times newer than the “built” file, it runs your script to rebuild them. Concatenating javascript files seems like the perfect opportunity for this. I’ll rewrite my bash script to use make, set it as a git hook, and should be able to forget it. Will let you know how it goes.

I had a bug that crept up on me that wasn’t found until right before a production push. I rolled back the last two commits locally but saw that the issue was still there on the iPhone. Now I’ve heard about the wonders of git bisect but hadn’t had the opportunity to use it – until now and was pleasantly satisfied at how well it did it’s job.

Locating the problem commit:

To quickly locate the exact commit that the issue was introduced I picked an arbitrary date of 15 days ago and saw that the bug didn’t exist at that time. I ran git bisect specifying master as bad and the the commit of 15 days ago as good. git bisect then picks random commits between those two commit ranges until I find the first bad commit. The process involves me calling git bisect bad or git bisect good as I refreshed the iPhone screen. The bug was found in less than five minutes (having called git bisect six times). Fixing the bug however, took a little longer…

For a greater look into git bisect peep this link.

Bonus round

Once you find the problem commit, you can show the details of the comment by doing:

git show 97d7c26dba17ba1a46fb9c6f0bf0e954a92aec74

Cat a specific file by doing:

git show 59010bee586296f0676a9e2255b2bade6b8cea74:public/js/jellycar3/tap.js

What to grab the previous commit before that file and copy it to your local branch? Just do (while in whichever branch):

git show 59010bee586296f0676a9e2255b2bade6b8cea74^:path/to/file/tap.js > tap.js

Lately, I’ve transferred all my repos over from Subversion to Git and have become familiar enough with the Git SVN bindings to even work on my work projects in Git while still being able to check-in as a regular SVN user.

I’ve found that some usual stuff Subversion would ignore in projects Git doesn’t. The Git exclude file doesn’t work here since these are files being tracked in the working tree that are just specific to your instance. After digging around, I found the proper command to ignore these files:

# ignore changes in a working tree file
git update-index --assume-unchanged .classpath