be·a·tyf·ic

The more I play around with git, the bigger fan I am becoming. At this point, I hope I never have to go back to using SVN (notice how I’m not linking here). I will most certainly be lobbying for the use of git on my future projects. But, I digress. This post is about two bits of awesomeness of the most excellent GitHub, the “Social Coding” git repository hosting service: User pages and Project pages. User pages allow you to host your own website on GitHub. Some people host their primary website on github. Here are a couple of examples:

http://schacon.github.com/ http://mbleigh.github.com/

Can you say “domain forwarding”? Can you say “free web hosting”?! I’m now trying to justify paying HostMonster over $100 per year for shared web hosting (note, I have nothing against HostMonster; it’s actually quite sufficient). I do like the WordPress, MySQL, etc. hosting I get from a hosting provider such as HostMonster, but I also like the idea of using a Ruby-based, open source, blog-aware framework like Jekyll and GitHub for hosting my web presence.

The other related nice feature that GitHub provides is Project pages – the ability to host project web pages for any regular repository, using a special branch named “gh-pages”. Note, I stress the word “regular” here, because it doesn’t seem to work for a forked repository. There’s probably a good reason for that, which escapes me right now, probably due to my lack of complete understanding of the nature of forked repositories. (Yeah, that was a lot of prepositions in there, I know.)

GitHub publishes a nice help page on these two page hosting features:

GitHub Pages

The GitHub guys also had a good blog post about these features way back when:

GitHub Pages (Blog)

Lastly, here’s a Gist someone posted about the setup:

Setting Up GitHub Pages

Gist? Wha? Yeah, another cool tool provided by the GitHub team. Check it out, if you haven’t already.

If you want to use an external editor for editing your commit comments (by omitting the -m flag on the commit command, there are a couple of things you need to be aware of for this to work correctly. First, make sure one of the following variables is set in your environment so git knows which editor to use. Note, git will look for these environment variables in the order shown.

• GIT_EDITOR (environment variable)
• core.editor (configuration setting)
• VISUAL (environment variable)
• EDITOR (environment variable)

You also must make sure that the editor stays in the foreground when it gets invoked, otherwise it will return control back to git right away and git will think you haven’t provided any comment, therefore not performing the commit. In this case, you will most likely see the message “Aborting commit due to empty commit message.”

I am on a Mac, so I like to use mvim (or gvim) to edit commit comments. I can use the -f switch (mvim -f) to keep the editor in the foreground. So, I have my GIT_EDITOR environment variable set to ‘mvim -f’. Other editors will likely have a similar switch option, so check out the documentation for whatever editor you would like to use.

Update: It is possible that the editor you are using will take the foreground by default, in which case you won’t need to use a command switch as I did for mvim.