Git isn't Chatty

Recently we deployed to production without a key bugfix and my assumptions about git were to blame.

We, like other people who use git, do a lot of our bug fixing in a branch and then merge it into master when it's time to release. So here's the procedure for the guy who's turn it is to do a deploy (which was me):
  1. Do a 'git pull origin master' in the master branch
  2. Get a local tracking branch of the bug-fixes branch
  3. Merge the bug fix branch into master
  4. Tag the master branch with the name of the release (our deployment keys on tags)
  5. Start the automated deploy script
Easy right? Except that my years with subversion have put in my brain this assumption that my source control will talk to the remote server all the time. But git's model is to use all your local info unless you specifically tell it to go over the wire. So when I told git to create a local tracking branch it did using the latest information it had locally about that branch. The last time I had done a general 'git pull' was a day ago so I got a version of the bug fix branch that was missing a commit that had happened the day of the deployment. And of course when I merged into master I was missing a crucial commit.

One of the cool things about git is the fact that you can do a lot of development without an internet connect, but I've found that a fair amount of the gotchas I've run into with git trace back to my expectation that it will talk to the remote server when it's preference is to stay local.

Comments

Unknown said…
If that's something you commonly suffer from, I'd recommend writing a git alias to do pull origin first before creating a local tracking branch, so you only have to remember one command and it will just do the right thing.
May 26, 2009 at 12:34 AM
Sam said…
I guess it is just a matter of shifting the paradigm in your head a well as with your SCM.
May 26, 2009 at 2:17 AM
Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more