has_many :thoughts

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.

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.

Note: This article is still on using Git under Tiger (10.4.10, respectively)... Until I have time to run down to the Apple store tomorrow and do a nice clean install of Leopard onto my Macbook, I will not have the appropriate means of writing a proper article on Git use under 10.5.

This is for anyone that reads this blog, and used my previous article on compiling Git. I left the proper Git tutorials to the behmouth of external articles out there, on using Git as Rails project/deployment SCM. I’m also a firm believer in DIY, and the same applies to learning new things. Nobody ever taught me a damn subject (completely) in person on anything I use day-to-day… so DIY and…

Welcome to the wonderful world of Git folks!

Since my last article, actually a day ago, Geoffrey Grosenbach over at Peepcode Screencasts released Video 015, on Git. This should really, visually, help out those that are really having problems crasping the simple things in Git. There are other numerous advances in using Git with your Rails applications. So I’ll keep things DRY here…

One thing I will update you with though, a quick and simple way to update your source compiled installation of Git, by using Git’s repository itself.

# git clone git://git.kernel.org/pub/scm/git/git.git
# cd git
# make configure
# ./configure --prefix=/usr/local
# make all doc
# sudo make install install-doc

You will now have a completely refreshed version of Git on your system.

Take note, Grosenbach mentions the benefits of having a compiled version of Git on your system. He does not, however, give more than a quick mention that it may be slightly difficult gathering up the proper dependency chain onto your system. That was what my previous article was for.

Enjoy, and let me know how things go for you… justin_at_kineticweb.com.

Update: Checkout the Leopard version of this OS X Git howto

The following is a step-by-step, dependency chain installation guide to getting up and running with Git on OS X.

Only one required version number was needed, docbook-xml v4.2, otherwise you can use the latest versions of the packages you will be installing, including Git (please note newer version of the below packages may require other dependencies).

You may have wget installed already, though this guide includes wget as it is not natively included in Mac OS X. This was needed to pull down docbook-xml 4.2 from the original wiki article I followed, noted at the bottom of this article.

The following tarballs were used for my installation, in alphabetical order…

asciidoc-8.2.2.tar.gz
docbook-xsl-1.73.1.tar.gz
expat-2.0.1.tar.gz
getopt-1.1.4.tar.gz
gettext-0.16.1.tar.gz
git-1.5.2.5.tar.gz
wget-1.10.2.tar.gz
xmlto-0.0.18.tar.bz2

1. Download and install expat; dead simple configure/make/make check/sudo make install

2. Download and install asciidoc; sudo ./install.sh (requires python >=2.3)

• rm doc/asciidoc.html
• asciidoc doc/asciidoc.txt
• Should re-generate doc/asciidoc.html

3. Download and install gettext; simple configure/make/make check/sudo make install

• Change root Makefile LDFLAGS=-lintl
• make/sudo make install

5. Download and install wget; dead simple configure/make/sudo make install

• sudo mkdir /etc/xml
• sudo xmlcatalog—noout—create /etc/xml/catalog
• Download and unpack docbook-xsl
• sudo mkdir -p /usr/local/share/docbook/xsl
• mv ./docbook-xsl-1.73.1/ /usr/local/share/docbook/xsl/1.73.1
• sudo xmlcatalog—noout \
  —add ‘nextCatalog’ ’’ ‘file:///usr/local/share/docbook/xsl/1.73.1/catalog.xml’ \
  —create /etc/xml/catalog
  
• sudo mkdir -p /usr/local/share/docbook/xml
• cd /usr/local/share/docbook/xml
• sudo wget -r -np -nH -l 0—cut-dirs=2 http://www.oasis-open.org/docbook/xml/4.2
• sudo xmlcatalog—noout \
  —add ‘nextCatalog’ ’’ ‘file:///usr/local/share/docbook/xml/4.2/catalog.xml’ \
  —create /etc/xml/catalog
  
• Download and install xmlto; simple configure/make/sudo make install

• make prefix=/usr/local all doc
• make prefix=/usr/local test
• sudo make prefix=/usr/local install install-doc

• rails some_stupid_demo && cd some_stupid_demo
• git-init
• git-add .
• git-commit -m ‘This is the beginning of a beautiful friendship’

http://wincent.com/knowledge-base/Installing_Git_1.5.2.3_on_Mac_OS_X_Tiger Taken from above url, but shortened (with some small modifications) from the trial-and-error description above.

A helpful start to using Git for Rails development can be found by the great guys over in the UK at New Bamboo… http://blog.nbwd.co.uk/2007/8/16/using-git-for-rails-development I’ve found this to be an excellent guide, as it includes git-svn for SCM with Git using current SVN repo’s.

Everday Git can be found here… http://www.kernel.org/pub/software/scm/git/docs/everyday.html