has_many :thoughts

We recently switched to git based capistrano deployments and I quickly found out that these weren’t working from my MacBook Pro. I noticed that my git version was a few behind my coworker’s, so I figured it was time to upgrade.

Following Justin’s original git compilation instructions, I downloaded and compiled the latest Git version, 1.6.2 like so:

curl -O http://kernel.org/pub/software/scm/git/git-1.6.2.tar.gz
tar jxvf git-1.6.2.tar.gz
cd git-1.6.2
make prefix=/usr/local all
make prefix=/usr/local test && echo $?
sudo make prefix=/usr/local install

When the compile was done, it gave me output like this:

!! You have installed git-* commands to new gitexecdir.
!! Old version git-* commands still remain in bindir.
!! Mixing two versions of Git will lead to problems.
!! Please remove old version commands in bindir now.

Thanks to this nice posting, I discovered this always happens when you upgrade to 1.6 and above. Git now only puts the main git binary and a few others in your /usr/local/bin and it tucks the rest away elsewhere. That meant that all the other zillion binaries needed to be deleted from my bin. I simply did:

cd /usr/local/bin/
ls -latr | grep git

Which gave me an ordered list of all the git binaries installed. The ones at the end all had today’s date on them, so I knew those were the new versions. The rest I could whack. The ones I could keep were git-upload-pack, git-upload-archive, git-receive-pack, git, git-shell, git-cvsserver, and gitk. The rest I removed like so:

sudo rm git-var git-update-server-info git-unpack-file git-ssh-upload git-ssh-push git-ssh-pull git-ssh-fetch git-show-index git-send-pack git-peek-remote git-patch-id git-pack-redundant git-mktree git-mktag git-merge-tree git-merge-recursive git-merge-index git-local-fetch git-index-pack git-imap-send git-http-push git-http-fetch git-hash-object git-fetch-pack git-fast-import git-daemon git-convert-objects git-bisect git-write-tree git-whatchanged git-verify-tag git-verify-pack git-update-ref git-update-index git-unpack-objects git-tar-tree git-tag git-symbolic-ref git-svnimport git-svn git-submodule git-stripspace git-status git-stash git-show-ref git-show-branch git-show git-shortlog git-sh-setup git-send-email git-runstatus git-rm git-revert git-rev-parse git-rev-list git-reset git-rerere git-request-pull git-repo-config git-repack git-remote git-relink git-reflog git-rebase--interactive git-rebase git-read-tree git-quiltimport git-push git-pull git-prune-packed git-prune git-parse-remote git-pack-refs git-pack-objects git-name-rev git-mv git-mergetool git-merge-subtree git-merge-stupid git-merge-resolve git-merge-ours git-merge-one-file git-merge-octopus git-merge-file git-merge-base git-merge git-mailsplit git-mailinfo git-ls-tree git-ls-remote git-ls-files git-lost-found git-log git-instaweb git-init-db git-init git-gui git-grep git-get-tar-commit-id git-gc git-fsck-objects git-fsck git-format-patch git-for-each-ref git-fmt-merge-msg git-filter-branch git-fetch--tool git-fetch git-diff-tree git-diff-index git-diff-files git-diff git-describe git-cvsimport git-cvsexportcommit git-count-objects git-config git-commit-tree git-commit git-clone git-clean git-citool git-cherry-pick git-cherry git-checkout-index git-checkout git-check-ref-format git-check-attr git-cat-file git-bundle git-branch git-blame git-archive git-archimport git-apply git-annotate git-am git-add--interactive git-add gitjour

Then I just had to go back and install the manpages for the new version like so:

curl -O http://kernel.org/pub/software/scm/git/git-manpages-1.6.2.tar.bz2
sudo tar xjv -C /usr/local/man -f git-manpages-1.6.2.tar.bz2

And, low and behold, I was now running git 1.6.2! What’s more, my capistrano deployments work now.

Just got this question and thought I'd make a blog post out of it.

why would someone want me to pull his changes into MY fork of this project?

This happens all the time, and usually for popular projects. There are a few reasons which lead themselves nicely into a discussion on Git[hub] distributed workflows.

The Short Answer

Git's distributed architecture can ensure that no single entity is the "central repository". Thus when someone feels they have important changes that all the forks and mirrors should utilize, they send out a global pull request to all or some of the forks on Github.

An Even Shorter Answer

It's a personal preference, one of Git's many available workflows.

Hardcore Forking

Personally, I have never worked that way on Github. I have done two things in maintaining forks.

• Fork fork; my fork is an entirely separate entity with a separate development cycle and process (or even end result)

• Support fork; my fork is a fork of the "sanctioned" main repo, and I am doing support work for the main project I will pull request to the "gate keeper" of that project (the main author or project maintainer).

Now if I really felt something was of urgency to all the forks I might do a global pull request if the main repo author didn't like my commit, he's gone AWOL and/or I still felt it was important (security, etc).

Otherwise, fork maintainers should have a local branch for tracking every other remote repository of other fork maintainer's. This is what I do to track only people I think have good commits that I can pull and include into my fork repo. Branches in this respect provide the links to other "node" repositories in the distributed glory which is Git.

Git suggests in their man pages and docs that you make the development decision to only pull in new commits, and never pushing out. Tracking remote repos demonstrates the beauty of following this workflow of "pull only".

Just Pull It

For shits and giggles lets build an example to demonstrate why "pull only" might be such a great idea for distributed project development.

I can think of no better example than Roy Fielding and the IETF's HTTP standard.

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext...

We are going to map the following HTTP technologies to git fetching commands.

• git-push maps to Comet, a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.

• git-pull maps to Ajax, an acronym which describes a web browser technology capable of requesting only the content that needs to be updated, thus drastically reducing bandwidth usage and load time.

Comet, in general, uses the web server to push updates to the browser when they are available. Handy at times but breaks the HTTP protocol. It requires the server-side to maintain a connection and known state as the server needs to know whom the client is and where to send the new data. As we all know that's not very efficient in the grand scheme of HTTP. State is tough to keep synchronized. It limits the ease of going on and offline, as well as the client moving around across the internet (changing IPs, etc).

In contrast Ajax requests are much lighter. The client maintains when to request new content. Thus making a decision of how to handle the content, what it is and where it's coming from. When you are only doing git-pull you are choosing what to add and where to add it. There is more control over your own repository.

Summing it all Up

In a distributed environment everyone becomes the gate keeper to their own repository.

This is great for open source projects because the code is always kept free from central dictatorship.

Power is gained through this autonomous workflow when you allow anyone, at any moment, to add changes and bug fixes to the project or pull down someone else's updates for review and merging.

By using Git, our workflows and environments are becoming much cleaner, there’s no denying that. I just wanted to post a quick note on how “squashing”, and more specifically interactive Git rebase, can extend that as well.

If your using Git you can squash tiny commits into a “lump sum” commit. This way you have the benefit of smaller commits while releasing only the real meat of changes your working on.

Its a tad dangerous messing with rebase, since it rewrites history, so try to learn how to do it on a separate test branch.

Personally, I’m trying to work this into my workflow by switching back to my master branch, merging down tiny changes from the other “working” branch, squashing them together, then pushing up (or others pulling down) or switching back to continue working/create a new branch for new functionality… whatever….

Plenty of people have blogged about this, so I’m not going to demonstrate how to do it, but here’s a link for learning more about it…

git awsome-ness [git rebase—interactive]

As usual, check the Git rebase manual page for more info…

I haven’t been around in awhile, frankly because I’ve had my own things to attend to… but I’ve felt somewhat ashamed that I’ve left my kind Kinetic audience a float. So here is another “Up and Running” treat. Cloning Merb-core and -more, from Git[hub] to dummy project.

BTW, it should be any day now for the official 0.9 release. Rumors have it that Ezra will be releasing it at ActsAsConference.

Preperation

Your going to want to remove any old gems in the following list, as you will be installing trunk versions in this tutorial.

merb (< 0.9)
merb_datamapper (< 0.9)
merb_helpers (< 0.9)
datamapper (< 0.3.0)

You can go ahead and gem install the following. I’ve listed the version numbers I use currently.

sqlite3-ruby (1.2.1)
data_objects (0.2.0)
do_sqlite3 (0.2.3)
do_mysql(0.2.2)
rack (0.2.0)

Along with the regular Merb dependencies listed in the API.

# gem install mongrel json json_pure erubis mime-types rspec hpricot mocha rubigen haml markaby mailfactory Ruby2Ruby -y

Thats a lotta gems right? Well, taking a closer look you should have most of these already… and if you don’t you should.

Installing Git

You installed it already, otherwise… EPIC FAIL!

You DO have a Github account

If you have a Github account, you’ll most likely want to fork merb-core and merb-more so you have your own fork’s to mess about with. If you find anything interesting you can always submit a bug/patch and help the wonderful Merb team out! Or start building some new framework forked from Merb. Either way…

To do this, login to Github and…

http://github.com/wycats/merb-core/fork
http://github.com/wycats/merb-more/fork
http://github.com/wycats/merb-plugins/fork

You’ll then want to clone these like the next section…

You DON’T have a Github account

If you don’t have an account yet for Github you’ll still need Git installed like I noted above. From within a fresh directory in Terminal run the following commands.

# git clone git://github.com/wycats/merb-core.git
# git clone git://github.com/wycats/merb-more.git
# git clone git://github.com/wycats/merb-plugins.git

Installing these Git forks/clones

Simply enter the directories “merb-core” and “merb-more” and run…

# sudo rake install

You’ll also want to do this under “merb-plugins/merb_datamapper” and “merb-plugins/merb_helpers”. Including any others in “merb-plugins” you would like installed.

Installing Datamapper Trunk

Currently, Datamapper is still under SVN. I’m positive this will change in the near future. But for now…

# svn co http://datamapper.rubyforge.org/svn/trunk/ data_mapper

Then simply go into the data_mapper/ directory created and do…

# sudo rake install

Merb-gen is your Friend?

I’ve just recently discovered that they’ve changed, yet again, the default way of creating a new Merb project. I guess because “merb -g” or “merb” was getting annoying, so “merb-gen [projectname]” is some how much simpler. You also use this to generate models/controllers/resources/etc… :/

I’m going to take another guess and say this is somehow based on the project directory no longer needing to conform to a certain structure like Rails. I’ve heard this, but I haven’t tested it out for fact… so let me know your experiences.

Either way…

# merb-gen lovely-app

Going into Toshi Station to pick up some power converters

This is where it starts to get exciting. The fruit of our labors dance in unison to form a euphoric aura called “0.9”... not so fast though.

1. If your not already, make sure your in the “lovely-app/” project directory.

2. Open up “config/init.rb” and uncomment…

use_orm :datamapper

Rspec should be your testing framework by default.

3. Back in your shell, run…

# rake --tasks

4. This should auto-generate “config/database.sample.yml“

5. Overwrite the entire thing with the following, and save as “config/database.yml”...

---
:development: &build
  :adapter: sqlite3
  :database: db/dev.db

:test:
  <<: *build
  :database: db/test.db

:production:
  :adapter: mysql
  :database: lovely_app
  :username: root
  :password: ""

6. Your going to now want to create those sqlite databases. If not both just db/dev.db.

# mkdir db/
# sqlite3 db/dev.db
SQLite version 3.5.1
Enter ".help" for instructions
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /Users/bionicebonics/lovely-app/db/dev.db                     
sqlite> .quit

You should be able to run a successful “rake—tasks” if you did everything correctly. You may also want to test and see if you can run the daemon, and pull up a browser window. Run “merb” by itself from Merb.root or project root directory.

In short, just start hacking! Reference the API for help, not me.

The Sugar

You should now have a base process for exploring Merb 0.9 development.

The Salt

If for some weird reason your getting errors running “merb”, make sure you removed any old versions of Merb <= 0.5.x.

Also try uninstalling merb-core and reinstalling it from a new Git clone of the main repo. I had to do this for some odd reason whilst running through this tutorial.

Shameless Kinetic/PhillyOnRails

Colin will be giving a talk on Merb at our local PhillyOnRails Users Group, so stay tuned for info on that.

Update

Gotta love Merb integrating Rack/WSGI!

Following a few discussions on the Thin webserver mailing list, I just tried Merb on Thin… this is working out excellent! I’ve also heard that Ezra just got 2200 req/sec using Thin.

If you would like to explore the possibilities of this incredibly fast setup, simply do…

# sudo gem install thin
# cd lovely-app
# merb -a thin

This will load Merb on Thin. If you don’t know about Thin, I’m not going to sit here and explain it. I’m just not like that. You’ll have to FOFY, find-out-for-yourself.

Just to not let my adoring Git followers down, since I have yet to write my next Git article… Garry Dolley over at http://scie.nti.st has an excellent article on Hosting Git repositories, The Easy (and Secure) Way.

Now I understand he uses Python, but lets face it, so does Git. Also, its only an excuse some Rubyists use for not learning that wonderful sister language.

Enjoy, and let me know your success/failures… or just never visit this site and keep reading our wonderful articles through NetNewsWire or what-have-you.

The following is the exact compilation steps I took for compiling Git onto the new retail version of Leopard. Definitely a big change since my previous article on installing in Tiger (next to pre-installed SVN, bye bye CVS!)...

curl -O http://surfnet.dl.sourceforge.net/sourceforge/expat/expat-2.0.1.tar.gz
tar zxvf expat-2.0.1.tar.gz 
cd expat-2.0.1
./configure --prefix=/usr/local
make
make check
sudo make install
cd ..

curl -O http://kernel.org/pub/software/scm/git/git-1.5.3.4.tar.bz2
tar jxvf git-1.5.3.4.tar.bz2
cd git-1.5.3.4
make prefix=/usr/local all
make prefix=/usr/local test && echo $?
sudo make prefix=/usr/local install
cd ..

curl -O http://www.kernel.org/pub/software/scm/git/git-manpages-1.5.3.4.tar.bz2
sudo tar xjv -C /usr/local/man -f git-manpages-1.5.3.4.tar.bz2

Notes

You may need to adjust your default MANPATH environment variable. You can either apply something along the lines of…

export MANPATH="/usr/local/man:$MANPATH"

...to your .bash_login, profile or what have you. Or you can look into editing /private/etc/man.conf (or un-tar the manpages into a directory in your MANPATH already).

Also, no need to fiddle around with SVN bindings for Perl, or whatever the problem was with git-svn before.

You may also wish to surf our past articles hear on this blog for upgrading Git. The upgrading should be identical on Leopard.

Next Time

My next article will cover developing outside of a traditional distributed Git environment. Using Git to manage personal branching/merging/local copies, then committing to a main SVN repo. Happy hacking.