Interactive rebasing is great
Nov 2nd, 2012 by Ken Hagler

One of git’s more powerful features is the ability to rewrite history with the rebase command. It looks a bit scary at first, but if you read the documentation carefully and know what you want to do before you start, it’s incredibly useful.

Case in point: I recently updated a large Python class to use the logging module instead of print statements (I wrote it many years ago when I was new to Python). I committed the changes for each method as I finished with it, as I didn’t want to worry about having a huge pile of changes in my working directory all at once. I had to do a fix in the master branch for a configuration change on the Perforce server in the middle of all this, so I was pretty happy with my strategy.

However, this left me with two dozen commits that all had nearly identical commit messages, because they were basically doing the same thing for each method. Using git’s interactive rebase (git rebase -i) I was able to quickly and easily turn all of those individual method commits into a single commit with a reworded commit message. That way I get a clean, easy to follow history without having to have all of those “216 lines added, 117 lines deleted” hanging over my head in my working directory.

Useful feature for CM
Mar 24th, 2012 by Ken Hagler

I really like the git blame command. In CM it’s pretty common for an irate developer to complain, “The build is broken, fix it!” Tools like this are very useful for figuring out what happened. Although I’ve found that in practice there’s a pretty good rule of thumb: the developer who complained is almost always the person who broke the build.

Amusing timing
Mar 20th, 2012 by Ken Hagler

Perforce is a Git Developer. We’ve been studying Git for some time. We like to keep an eye on players and technology in our space, partly because it’s something we think our customers appreciate, partly because it’s due diligence as a leader in the SCM/Version Management space, and partly because it’s just plain interesting! But something unexpected happened last summer as a result of this study of competing technologies: the relationship between Git and Perforce turns out to have synergistic appeal with a peanut butter twist, as outlined in my blog articles Perforce and DVCS: Two great tastes that taste great together and Git as a Perforce Client.


But if you want to use Git and Perforce together today, you’ll likely be looking at the git-p4 feature of Git as either a tool or a starting point. So to get you a little further along the road, we’ll be making an increased effort on git-p4 in the coming months. Here’s where you can give us a hand: letting us know what’s important to you in a git-p4 feature set. Please add your suggestions to the comments below! [p4 blog]

I just started trying out git-p4 yesterday for a very small internal tool, so this is really good news. As a CM Engineer, I pretty much live in Perforce, but it’s a bit awkward for working on small internal tools where I might want to have several experimental branches. I’m quite new to git, but I’ve already found that its capability for that sort of work more than lives up to the hype.

»  Substance:WordPress   »  Style:Ahren Ahimsa
© Ken Hagler. All rights reserved.