Version number change.
Basic handler and test for Mustache templates
Fixing mistake in the handler chain definition
Added Mustache to gemspec
Merge branch 'master' of github.com:lance/awestruct

Conflicts:
	lib/awestruct/version.rb
[issue #140] ordering issue for same-day posts

* check for the post's date prior to build a date
  for the source path to let posts be correctly order on the same
  day
[Issue #139] Add variable interpolation to *.js files.
Merge remote-tracking branch 'upstream/master'
Merge pull request #142 from lance/master

Variable interpolation in javascript files
Add support for GitHub Pages deploy target Repository

Property: repository (default: origin)

    The "remote" repository that is the destination of the push operation.
    This parameter can be either a URL or the name of a remote.
    (ref: git help push)

Example:

    deploy:
      host: github_pages
      branch: master
      repository: upstream
Ensure that InterpolationHandler handles regular expressions in input.

Issue #139 exposed a problem with how awestruct handles interpolation.
This isn't really a javascript-specific issue, rather it was a broader
problem with the InterpolationHandler and how it dealt with regular
expressions in an input file.
Only use negative look-ahead regexp with ruby 1.9. It's not available in 1.8.
Issue #139 - only handle in 1.9 mode
Merge pull request #144 from lance/master

Ensure InterpolationHandler correctly deals with '#' in its input.
Issue #50 - Add a redirect handler.

With this handler, you can now have a file /somedir/somefile.redirect
which should contain only a URL. RedirectHandler will use this to create
a file /somedir/somefile.html which has nothing but a <head> section
with a <meta http-equiv..> redirect to the URL contained in the original
file. You may also use variable interpolation, so that the .redirect
file can contain something like http://#{site.redirhost}/. See the spec
redir_handler_spec.rb for an example.
Merge pull request #145 from lance/master

Add a redirect handler
Refactor deployers. Extract common behavior to Awestruct::Deploy::Base
Adjust symbol/string handling on Awestruct::Deployers and add initial s3 deployer stub.
Spawn regeneration thread in Dev mode

Spawn a new thread when the Guard listener detect a change on a monitored file.
The new thread will perform the normal site regeneration, but the Guard listener
is now free to receive new events.

If a new change event on the same path as currently running is detected, the running
thread(if any) will be killed, and a new thread is spawned that starts the
regeneration again. If a different path is changed, the started regeneration is
allowed to finish before the new path is regenerated.

This allow the user to make multiple rapid changes to the same template without having
to wait for the re-generation of all the dependent pages to finish before the
current working template is regenerated.
Add individual tracking of content and variables

Changes to Front Matter variables are only read once and updates are
never reflected to the Page object as they can be changed by the pipline
which only run during startup. Tracking dependencies between Page objects
for both content and variables as one is wastefull in this scenario as
a lot of Pages will depend on each others variables, but very few on their
content. Regenerating a Page because a dependency has changed Front Matter
has no effect on the output (the old variables are used).

Instead track content and variable dependencies individually, but only
trigger regeneration of dependent Pages if content has changed.
The content and Variables are hashed using SHA256 which allow us to detect
a real change, and not just the a file has changed modify time.

When a change event occure, the following steps are taken:

* Locate the Page for the given Change event Path
* Trigger regeneration of that Page
* If that Page's Content has changed
    * Find all dependent Pages and trigger regeneration
* If that Page's variables have changed
    * Warn that a restart is required for the change to take effect

The corresponding Page to a changed path will always be generated first,
before its depending pages. The depending pages are sorted by last modified
time. This allow the regeneration process to start with 'the most interesting'
pages first to give the user a quick feedback on change, while updating
the complete dependent tree in the 'background'.

> Page variable dependencies are still tracked, but not currently used.
> A possible usecase could be to display a Page's dependencies as debug info.