Ryan Tomayko

Rebase is a powerful tool, and with great power comes great responsibility. It's easy to get stuff wrong with rebase, and it's also hard for most developers to get their heads around because it offers something that no other VCS does. I'm also very much reminded of http://tomayko.com/writings/the-thing-about-git, except to extend it even further, most VCS will tell you "you should have not committed broken code or written a bad message" or "you should have cleaned up your patch before committing it." Git, on the other hand, is extremely forgiving. I've lost count of the number of times I've gone off the rails and deleted a branch name or some other pointer to a commit in git, yet I could always pull it out (even if I had to resort to reflog). But enough about my shortcomings; why should you rebase?

I can think of two very good reasons to rebase: to cleanup a patchset before submitting it to a "central" repo, and to move your patch forward on top of another patch set (avoiding a merge). Often times, you might be working on something and get distracted, so you stash or commit and come back to it later. For whatever reason, you may have multiple commits that are conceptually related, but are separate. With git, it doesn't matter if these commits are one right after the other, or separated by other commits. You can rebase them into one commit that makes conceptual sense. If one commit reverts part (or all) of a previous commit, once you rebase and squash them together, the…

Here are my top ten, mostly web-related in some way because of my interests. These are the "loud alpha geeks" - the ones who broadcast their interests via regularly-updated blogs or curated links. (There are plenty of "quiet alpha geeks" who are just as "alpha" but not as easy to follow online.)

Brad Fitzpatrick (http://brad.livejournal.com/) - creator of LiveJournal and Danga, now at Google working on PubSubHubbub, the Social Graph API, etc.

John Resig (http://ejohn.org/, http://news.ycombinator.com/user?id=jeresig) - jQuery, Mozilla, lots of other JavaScript and browser stuff.

Paul Bucheit (http://news.ycombinator.com/user?id=paul) - creator of GMail and FriendFeed, now at Facebook.

Ryan Tomayko (http://tomayko.com) - Ruby, Sinatra, now working at GitHub, has an excellent linkblog.

Simon Willison (http://news.ycombinator.com/user?id=simonw) - Django, Python, also has an excellent linkblog.

Leslie Orchard (http://decafbad.com/) - Previously at Delicious/Yahoo, wrote books on JavaScript, Dojo, RSS, now at Mozilla. Follow his bookmarks at: http://delicious.com/deusx

Mark Pilgrim (http://diveintomark.org/) - Atom, HTML5, Linux, Python, Greasemonkey, formerly at IBM, now at Google. Bookmarks at: http://delicious.com/wearehugh

John Gruber (http://daringfireball.net/) - Apple news and punditry, linkblog.

Sam Ruby (http://intertwingly.net/blog/) - Atom, Python, Ruby, Rails, XML, HTML5, SVG. Read what he reads at: http://planet.intertwingly.net/

Kevin Kelly…

In git, a use case for rebase that I'm intimately familiar with is interoperability with SVN. You can maintain a branch that's a mirror of an SVN repository, but if you do any merging and then try to check the results into SVN the result is a train wreck. In the somewhat acid words of the git-svn manpage:

Running git-merge or git-pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you've made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch.

The proper technique is to make a branch based on your SVN repo, make a bunch of changes on the branch (using svn rebase to keep your development branch in sync with changes on the SVN master branch, and -- god help us -- diff-and-patch if you have to merge in changes from some other git branch; this is your penance for working on an SVN-hosted project), then commit the whole thing back to SVN once you have it in shape. It sucks compared to true-blue git but is still nicer than SVN, because (e.g.) you get things like...

... the other use case for rebase, git-rebase --interactive, a.k.a. "take the last N commits and let me reorder, combine, and edit them however I want." I love this feature. See:

http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive

For more useful ravings about git's…

> I really don't understand how the world of iOS development has become one of the most cloistered developer communities in recent memory. Is it the gold rush mentality, maybe?

You must understand that the iOS development community has its roots in decades of engineering community, coming from NeXT, Mac OS and UNIX traditions.

We're simply not interested in the subpar engineering that comes from the inexperienced web developers joining the gold rush.

> Edit: Also...since when have "hacker" and "respect for knowledge gained over 20+ years" ever had anything to do with each other? Take the "knowledge gained", evaluate it on its merits, and if you find it lacking, who cares over how many years it was gained?!? If you think you can do better, do so.

Which is why we've watched the Rails community re-invent the wheel repeatedly over the past 6 years, consistently rediscovering abandoned methodologies, and then rediscovering why those methodologies were abandoned.

One of my favorite examples was the the breathless enthusiasm at the rediscovery of the (inefficient, abandoned) pure pre-fork model: http://tomayko.com/writings/unicorn-is-unix

Or, watching the extremely poor architecture of Rails waste vast troves of server CPU and RAM.

Or any other of the hundreds (thousands?) examples of junior engineers ignoring history and re-inventing failed architectures that would not have been so broken if they looked at what came before with anything other than disdain.

Actually, one of the benefits of Git over, say, Subversion, is that it's much easier to hack away on multiple things, and then arrange a series of sensible, self-contained commits from your messy working directory.

It's not necessarily a great way to work at all times, but it's a handy facility to have. Personally I use it most in the early, somewhat experimental stages of a new feature or project, when I find it useful to mentally separate experimental hacking with organised committing.

For most things, though, I try to focus on one thing at a time, and here Git's quick-'n'-easy branching and merging helps out. Whenever I start something new, even if it's just fixing a minor bug, I'll create a new branch just for that work, often naming it after the ticket number in our issue tracking system. Then your being in that branch is a constant reminder of what you're supposed to be working on.

Ryan Tomayko has written a good article on these aspects of Git here: http://tomayko.com/writings/the-thing-about-git

Things I couldn't live without (or at least would push back on if pressured to use something different):

git (GitX for viewing), TextMate (AckMate bundle for searching w/in a project), Basecamp, Chrome (any WebKit or Gecko browser will do though), two Fluid SSBs for personal and business Gmail, Homebrew for Mac package management, Hex Fiend for looking at/searching through raw files (priceless for diagnosing character set issues).

I'm using Sequel Pro, but I've found it a bit unstable and would love to see something better.

I just discovered Path Finder, a finder replacement that looks like it fixes my common gripes. I'll probably end up buying it when the demo expires.

Lastly, one I haven't used in awhile and is a little project specific is Prince for HTML->PDF conversion using CSS3 Print Profiles (and this was back when it looked like CSS3 would never happen). Here's a rundown: http://tomayko.com/writings/princexml