This edit made in a clone.
I need to learn about the staging area in git.

<div id="git-add">
  <quote src="http://learn.github.com/p/normal.html">
    Git uses the 'git add' command both to begin tracking files and also
    to stage changes to them.
  </quote>

  This confused me at first, because git add does 2 distinct things.
  Imho, a well designed command does one thing, even though it may
  involve multiple subtasks. Telling git "this is a new file that
  should go in the next commit", and telling it "changes to this file
  should go in the next commit" are two <emph>completely different
  things</emph>; therefore, their combination is an <emph>unholy
  marriage</emph>.

  <div class="in-retrospect">
    Maybe the way `git add` works seems strange to me because I've
    been using svn for a while. In svn commiting file modifications
    and file additions are very different because for modifications,
    you only have to do `svn commit`; but for additions you have to do
    `svn add` before doing `svn commit`.
  </div>

  Also, the implicit place where things are added when you use this
  command is the staging area. From this, you would infer that `git
  remove` would also implicitly refer to the staging area i.e. do the
  opposite of `git add`. After realizing that that command doesn't
  exist, I discovered `git rm`. That doesn't do the opposite of `git
  add` either! Eventually, I figured out that `git reset` is what I
  was looking for. This is very non-intuative for two reasons:

    <li>
      In English, "reset" is not the opposite of "add"
    </li>
    <li>
      The argument of `git reset` is a file, which this command does
      not change. What this file changes is the staging area.
    </li>

  Anyway, this sentence is key, because I was wondering about what
  `git commit -a` does, because it seems to be analogous to `svn commit`.
  At this point, I don't believe that's true, because `svn commit` would
  not commit new file unless you had previously done `svn add` on them;
  whereas, it seems like `git commit -a` would commit such files, because
  this command (supposedly) equivalent to doing `git add .` followed by
  `git commit`.
</div>

<div id="what-a-branch-is">
  <quote src="http://learn.github.com/p/branching.html">
    in Git, branches are simply lightweight pointers to a particular
    commit. The history is simply figured out by traversing the
    parents, one commit at a time.
  </quote>

  <a href="http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/">
    The difference between branching in git vs. hg.
  </a>
  This is a greate article! Comparing the way these work aid in
  understanding both. I also learned that hg has various ways of doing
  branching. If/when copying bookmarks on hg clone gets implemented,
  they will pretty much work just like git branches.
</div>

<div id="private-branches">
  <quote src="http://learn.github.com/p/branching.html">
    Git also importantly lets you keep these branches private if you
    want - simply don't push them.
  </quote>

  This is cool :).
</div>

<div class="branch-management">
  You will not switch branches when creating a branch. I guess this
  follows my "a command should do exactly one thing" principle, but
  for some reason, I was surprised that I had to do another command,
  namely `git checkout <new-branch-name>`, to switch to my new branch :/
</div>

<div class="confict-resolution">
  <quote src="http://learn.github.com/p/branching.html">
    When you're done fixing [the merge conflict], all you have to do
    is run 'git add' on the file to re-stage it, which marks it as
    resolved. Then commit the merge.
  </quote>
</div>

I just found out about configuring git to work with my github
account... after having already made some commits :(. You'd think that
my ssh private key would be enough link my to my github account, but
apparently not.

Gah! I set github.username instead of github.user. Take 2.