Git tips from the trenches

> will prevent you from getting stuck resolving the same merge conflicts repeatedly, by remembering how you resolved them the last time.

That's on by default these days; if you re-do a merge and git finds the conflict in rerere, it'll automatically use the saved resolution rather than inserting conflict markers.

Agree, tig is awesome and in my opinion the best git GUI (or at least representation). Use the normal commandline tools for commiting/cutting/rebasing/... and tig to see where everything is at!

+1 for tig. Definitely my favourite git interface. Its status view is also very handy for viewing diffs, and adding/removing files to the index, as well as reverting changes.

Also, it now has mouse support. I know this, cos I added it :)

Here's a tip for anyone using bisect with a Rails app (or any system that uses database migrations):

I do a rake db:migrate after a pull to make sure the database schema is up to date. So the first time I used git bisect on a Rails app, I figured I would use db:migrate after each bisect step.

On this project, as in many Rails projects, schema.rb is checked into git along with the migration files.

Somewhat mysteriously, after some of the bisect steps and db:migrate operations I was seeing an uncommitted schema.rb that was different from the one in git. That shouldn't have happened, I thought.

I finally figured out what perhaps should have been obvious: db:migrate was working fine when bisect moved forward in the history, but it was messing up when bisect moved backward across a migration.

Rails experts will know what went wrong here: After bisect moved backward, the db:migrate had no way of knowing which database changes to reverse, because the migrations that were now in the "future" relative to the latest checkout were removed before I ran the migrate.

I fixed it by using db:reset instead of db:migrate, at least after bisect moved backward in time.

Another bisect tip: Sometimes it can be advantageous to run the equivalent of a bisect manually instead of automatically. For example, you may have some pretty good hunches about which commits may or may not be related to the problem. Or you may want to do a db:migrate before moving back in time to avoid the problem I described above, and by doing the checkouts manually you will know which migrations to reverse before doing the checkout.

In my case, I was looking at a somewhat intermittent bug. As I narrowed down the possible bad commits I wanted to keep track of the specific ones I'd looked at, and git bisect doesn't do this for you. So each time I checked out a different commit I created a local branch first on the commit I'd determined to be (likely) good or bad, giving them names like Good1, Good2, Bad1, Bad2, etc.

This way I could just look at the history as I went along and see at a glance which commits I'd investigated so far.

I guess this trick would work with git bisect as well - just create a local branch before each bisect step.

There may be some better way to do this, but it worked pretty well for me.

BTW, I use SmartGit/Hg and really like it. I know everyone likes their command lines, but I greatly prefer a visual way of working with a source code repo.

error: Cannot delete the branch 'master' which you are currently on.

alias gclean='git remote prune origin; git branch --merged | grep -v -E "(\*|master)" | xargs -n 1 git branch -d'

I'm a neat-freak when it comes to file placement, and have a ~/tmp directory specifically for dropping one-off files without cluttering up repos and such.

Are the things your repo isn't tracking mostly temporary/build files? or things that are going to be checked in eventually?

Mostly because this helps me keep a clean history, which is something I value highly.

And for all the GUIs available, most of them either don't even touch blame, or just return the output of the CLI blame command. The only GUI I've seen so far which makes it easy to traverse history through blame is for bazaar (qblame/qannotate).