Farktronix

Mark Pilgrim on Mozilla not participating in the race to pass Acid 3:

“C’mon, guys. It’s not the score that matters, it’s the followup. It’s the conversation you have, the promises you make, the progress you show the next day and the day after that and the day after that. And bitching about an openly developed test suite whose ultimate goal was just to get people excited about web standards for a few minutes — man, you should all be embarrassed with yourselves. But you’re not, so here I am stepping up, publicly being embarrassed on your behalf. No need to thank me.” 

When the fall is all that’s left [dive into mark]

My Favorite Easter Egg

For a short while, if you broadcast just the right bits into space at just the right time, you’d get this in response:

 (.|.)
  ).( "chicks dig satellites"
 ( v )
  \|/

Great Software License

 ** The author disclaims copyright to this source code.  In place of
 ** a legal notice, here is a blessing:
 **
 **    May you do good and not evil.
 **    May you find forgiveness for yourself and forgive others.
 **    May you share freely, never taking more than you give.
 **
 *************************************************************************

Reverting an accidental git merge

One thing that’s bit me a couple times while using git is that I forget that the git-merge command behaves differently than svn merge.

A subversion merge creates a patch from the given revisions and applies the patch to your current working copy. You can then review the changes and commit if you’re happy with the result.

Git works a bit differently. If you don’t specify any additional flags and there are no conflicts, the merge will take every commit from the branch and “interleave”  those commits with the current branch. There is no review and commit step.

More than once I’ve run a git merge expecting it to behave like a svn merge, only to be surprised to find that the merge resulted in something far more serious than I was expecting. This isn’t git’s fault, it’s just bad expectations on my part from a history of using subversion.

How to un-merge in git

So you’ve just run a git merge and realized you made a huge mistake. The branch had multiple commits in it, and they’re all mixed in with the history of the current branch. Manually reverting each change would take a long time. How do you get back to the state you were in before the merge?

The short answer is to find out what your previous head commit was and run a git-reset --soft [commit] to reset to the state you were previously in. 

There are two ways to find out what your previous HEAD was: look through git log until you see the commit you remember as being the last one in this branch, or run git reflog and find the most recent line that looks like this:

9afb4f2... HEAD@{4}: checkout: moving from SomeBranch to CurrentBranch

The first seven letters and numbers there are enough to uniquely identify the commit. Use that as the commit number to reset to.

Don’t worry about the fact that the other branch’s commits are all mixed in with your current branch- everything will be sorted out after the reset. For an explanation of why, read on.

Behind the scenes

What’s going on behind the scenes in a git merge? To understand that, it helps to know more about how git tracks changes.

Every commit identifier in git is a sha1 hash comprised of the current state of all the files in the working copy, the commit tree leading up to the current commit, and the commit message itself (along with some other bookkeeping like timestamps and signatures). This means that if a file is altered in any way, the commit hash must necessarily change. The same applies if the parent of a commit is altered in any way. A specific commit hash is exactly associated not only with the state of the files in the tree, but also with the entire history leading up to that state.

When I realized this a lot of other aspects of git started to click into place. Every commit hash uniquely identifies the entire state of the project. Branches are nothing more than an alias to a commit hash. If you make a commit on a branch the branch just updates to point at the new commit.

You may have noticed that the commit hashes didn’t change after the merge. If every commit is a hash of the state of the tree, how can you stick new commits underneath it without changing the hash value? The trick is that the histories remain as two separate trees, but the merge commit is what binds them together. The merge commit is the hash of the result of merging the files combined with the hash of both separate history trees.

Because the trees remain separate, you can easily switch back to your previous state by making one of the trees your new head with git-reset. git-log may show the two histories as intertwined, but the two separate trees still remain. Any of the preceding commit hashes represents the entire tree in the state before you made the merge.

Try it Yourself

If you want to play around with a repository in this state, I’ve set up an example on github.