First of all, get the git bundle.

newtricks:~ ted$ cd ~/Library/Application\ Support/TextMate/Bundles
newtricks:Bundles ted$ git clone git://gitorious.org/git-tmbundle/mainline.git Git.tmbundle
Initialized empty Git repository in /Users/ted/Library/Application Support/TextMate/Bundles/Git.tmbundle/.git/
remote: Counting objects: 5018, done.
remote: Compressing objects: 100% (1612/1612), done.
remote: Total 5018 (delta 3342), reused 4957 (delta 3303)
Receiving objects: 100% (5018/5018), 634.79 KiB | 181 KiB/s, done.
Resolving deltas: 100% (3342/3342), done.
newtricks:Bundles ted$

Then, invoke Textmate and navigate to Bundles->Git->Administration ->Update Git Bundle. The following screen appears.

Here are some references.

http://gitorious.org/git-tmbundle
http://blog.macromates.com/2008/git-bundle/

This Textmate git bundle seems to work pretty well. Here's how I tried it out. First of all use Textmate to open a file that is a member of a git repository. Make a change and save it. Then, from the Textmate window do a Bundles -> Git -> Commit.

Double click on the filename in the Choose files to commit pane. A Textmate window opens up that shows the file in a diff format.

Write a description in the Summary of changes pane. Click commit. The window with the Summary and Commit button disappears and the other window shows what happened.

I still have the two Textmate windows open. Close the one with the diff and select the one with the file. Then, from the Textmate menu do a Bundles -> Git -> Log, and the following window appears.

The one that came with git really doesn't work well. My suspicion is that this problem has more to do with Snow Leopard than the git gui.

Type git gui on the command line. The prompt does not return. The result is variable. Today, nothing happened. Well, I got a git icon in my taskbar. For a while it bounced up and down. Now it is doing nothing. Click on it, and I get the following.

That quit button works. But the menu on the top of my desktop has the Quit Git Gui entry shaded out. In fact, most of the menu entries are grayed-out. I quit by issuing a Control-C in the command window in which I invoked git gui. The prompt returned.

Type git gui again. Now the git screen comes up; remember, it didn't before.

So I click on Open Existing Repository and browse to guess what, an existing repository and click Open.

 

Note the menu bar. It says Git Gui Apple Repository ... Now when it first came up, it didn't look like the figure below. I clicked on Amend Last Commit. This caused the filename to appear in Staged Changes. I then clicked on the filename, and its text appeared in the upper right pane. The change is shown in green.

Two things are key here. One, most of the menu entries are still disabled. Two, the menu bar is what it is. It will change soon.

 

Click on New Commit. Then, right click in the empty space of the upper right pane and choose Options. An options window appears. Click Save. The options window goes away. Now the menu entries are no longer disabled. Sigh. Does this make sense? Not to me.

Click on Repository and from the dropdown, choose Create Desktop Icon. Give the Desktop Icon a name and click Save. Then Click on Git Gui and choose Exit.

Now open the Desktop Icon. Note now that the menu bar entries are different. And now git gui seems to operate as it should.

None of this makes sense to me. This is not the gui I want to use.

So what am I going to use? I installed Textmate's git bundle. So far it looks good. I'll also check out the git plugin for Eclipse.

I wanted to try out git on the Mac. I'm reading the book Pragmatic Version Control Using Git by Travis Swicegood. There's a forum discussing this book on the Pragmatic Programmer's site, http://forums.pragprog.com/forums/64. The forum seems to be more focused on reviewing the book than discussing git issues, however.

Installing and Configuring

I have a Mac Book Pro (Intel) with Snow Leopard. To get MacPorts I went to the site http://www.macports.org/install.php and clicked on Snow Leopard.

Once MacPorts is installed, I issued the command

newtricks:~ ted$ sudo port install git-core +svn +doc

There's a Pragmatic Programmer forum entry that discusses how this macport installation of git did not work, but it worked fine for me. I can tell git is installed and working by checking its version.

newtricks:~ ted$ which git
/opt/local/bin/git
newtricks:~ ted$ git --version
git version 1.6.5.7
newtricks:~ ted$

There are only two required configuration values: user.email and user.name. Here's how you set them; they are silent commands.

git config --global user.name "Ted Kubaska"
git config --global user.email "ted.kubaska@gmail.com"

Although not required, the configuration value color.ui is useful. It color codes various git output. I'll show some examples later.

Display the configuration as follows.

newtricks:~ ted$ git config --global --list
user.name=Ted Kubaska
user.email=ted.kubaska@gmail.com
color.ui=auto
newtricks:~ ted$

Creating a Git Repository

Creating a git repository is pretty easy, in fact trivial. Just make a directory, enter it, and issue a git init. Then you can add files into this repository with git commit. This directory will be the working tree of code you check out from the repository. The repository metadata is in the directory/.git, and, guess what, its contents don't look like CVS.

So I do this ...

newtricks:GitRepo ted$ mkdir tedsrepo
newtricks:GitRepo ted$ cd tedsrepo/
newtricks:tedsrepo ted$ git init
Initialized empty Git repository in /Users/ted/GitRepo/tedsrepo/.git/
newtricks:tedsrepo ted$ ls -a
. .. .git
newtricks:tedsrepo ted$ pwd
/Users/ted/GitRepo/tedsrepo
newtricks:tedsrepo ted$

Then, in that directory, make a file (call it hello.html) to add to the repository.

newtricks:tedsrepo ted$ git add hello.html
newtricks:tedsrepo ted$ git commit -m "Initial checkin for hello.html"
[master (root-commit) f2c49ba] Initial checkin for hello.html
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 hello.html
newtricks:tedsrepo ted$ git log
commit f2c49baf3abafefb03b941db75ae4c026b0c877e
Author: Ted Kubaska <ted.kubaska@gmail.com>
Date: Tue Dec 29 21:07:15 2009 -0800

Initial checkin for hello.html
newtricks:tedsrepo ted$

Make a change in hello.html. Before you can commit the changed file, you must stage it. This is something that seems unique to git. You edit a file, and then you can't just commit it ... you must stage it first.

newtricks:tedsrepo ted$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: hello.html
#

no changes added to commit (use "git add" and/or "git commit -a")
newtricks:tedsrepo ted$

Notice that a modified, but unstaged file is shown in red. This is a result of that color.ui configuration value.

So stage the file before committing. Stage with git add. Note that the filename becomes green.

newtricks:tedsrepo ted$ git add hello.html
newtricks:tedsrepo ted$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: hello.html
#
newtricks:tedsrepo ted$

Then, commit.

newtricks:tedsrepo ted$ git commit -m "added head and title"
[master 4b7d2f1] added head and title
1 files changed, 3 insertions(+), 0 deletions(-)
newtricks:tedsrepo ted$

Branches

With CVS, I've always been very careful not to proliferate branches. But I think (from what I've read so far) that branches are key to the way people use git.

The name of the default branch in git (the branch you start with, the mainline, if you will) is called master. Master in Git is what I would call HEAD in CVS.

I thought it was interesting that you can create a branch, checkout the branch, edit a file and commit it to the branch. Then, checkout the master and edit and commit. You now have one version of the file in the branch and another in the master. Now if I rebase the master, the file in master has the changes that were made in the branch as well as the changes made on master. This sounds like a merge to me, although it's not technically a merge because there is a merge command. I suppose I'll see the difference when I start using the merge commands.

Here's what I mean in more detail. The following figure illustrates the actions I'm describing.

Let's say I'm on the master branch of my git repository. I put three lines in that file. I commit the file, then make a branch called R1.0. I edit the file again while still on master (the file now has four lines) and commit it.

Master line 1
Master line 2
Master line 3
Master line 4 <-- this is the line I added on master (not the branch)

Then, I checkout the branch and edit/commit the file.

Master line 1
Release line 1 <-- this is the line I added on the branch (not master)
Master line 2
Master line 3

Then, I checkout the master and rebase master with the branch. My file now has the changes from both the branch and master.

Master line 1
Release line 1
Master line 2
Master line 3
Master line 4

Here's the output I got from the rebase command.

newtricks:tedsrepo ted$ git rebase R1.0
First, rewinding head to replay your work on top of it...
Applying: added 4th master line
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging hello.txt
newtricks:tedsrepo ted$ git branch -d R1.0
Deleted branch R1.0 (was f3a999b).

As I said, it looks like a merge to me, but I've more to learn.

What is also interesting is that (with the branch checked out), you can tag it. Then, you can checkout master, rebase master with the branch, and actually delete the branch. You can restore the branch by make a new branch from the tag, like ...

newtricks:tedsrepo ted$ git branch R1.0 1.0

where 1.0 is the tag. I made the tag when the branch (called R1.0) was checked out as

newtricks:tedsrepo ted$ git tag 1.0 R1.0