Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Comparing changes

Choose two branches to see what's changed or to start a new pull request. If you need to, you can also compare across forks.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also compare across forks.
  • 3 commits
  • 2 files changed
  • 0 commit comments
  • 2 contributors
View
2  _posts/2009-04-29-jekyll-meets-dreamhost-automated-deployment-for-jekyll-with-git.markdown
@@ -104,4 +104,4 @@ Jay Williams followed this guide and experienced an annoying problem with the Gi
#### Updated 2009-10-29
-I no longer recommend using this configuration for deployment. See [simpler deployment for Jekyll using a Rakefile and rsync](/2009/10/29/simpler-deployment-for-jekyll-using-a-rakefile-and-rsync.html).
+I no longer recommend using this configuration for deployment. See [simpler deployment for Jekyll using a Rakefile and rsync](/2009/10/29/simpler-deployment-for-jekyll-using-a-rakefile-and-rsync/).
View
2  _posts/2009-10-29-simpler-deployment-for-jekyll-using-a-rakefile-and-rsync.markdown
@@ -3,7 +3,7 @@ layout: post
title: Simpler Deployment for Jekyll Using a Rakefile and rsync
---
-Earlier [I wrote about using Git and its post-receive hooks for deployment](/2009/04/29/jekyll-meets-dreamhost-automated-deployment-for-jekyll-with-git.html). After using this configuration for six months, I've concluded that it's unnecessarily complicated for my requirements. [Scott Kyle](http://appden.com/personal/journey-to-jekyll/) and [Ben Vinegar](http://www.benlog.org/2009/10/8/blog-now-powered-by-jekyll/) agree. Using such a configuration makes perfect sense for projects residing on GitHub. The repository already exists, and it's a complimentary service that you don't have to configure. In future, when someone asks me how they should deploy Jekyll, I will recommend using a [Rakefile](http://github.com/tatey/tatey.com/blob/master/Rakefile) and rsync. Thanks to Scott Kyle for sharing his [Rakefile](http://github.com/appden/appden.github.com/blob/master/Rakefile).
+Earlier [I wrote about using Git and its post-receive hooks for deployment](/2009/04/29/jekyll-meets-dreamhost-automated-deployment-for-jekyll-with-git). After using this configuration for six months, I've concluded that it's unnecessarily complicated for my requirements. [Scott Kyle](http://appden.com/personal/journey-to-jekyll/) and [Ben Vinegar](http://www.benlog.org/2009/10/8/blog-now-powered-by-jekyll/) agree. Using such a configuration makes perfect sense for projects residing on GitHub. The repository already exists, and it's a complimentary service that you don't have to configure. In future, when someone asks me how they should deploy Jekyll, I will recommend using a [Rakefile](http://github.com/tatey/tatey.com/blob/master/Rakefile) and rsync. Thanks to Scott Kyle for sharing his [Rakefile](http://github.com/appden/appden.github.com/blob/master/Rakefile).
#### Updated 2009-11-02

No commit comments for this range

Something went wrong with that request. Please try again.