On Tue, 2 Jun 2015 07:26:54 -0700 (PDT)
Márcio Moreira <mar...@verdesaine.net> wrote:

> We are using Pelican, a static site generator, to generate our web
> site. We write markdown formatted text files to a "content" folder
> and Pelican generates HTML files to an "output" folder. 
> Our goal is that the site could be edited by some collaborators
> sharing its work through a repository on our local linux server.
> Every time a commit is pushed to the local server, we wish the output
> folder (or the complete working dir) is pushed  to another server, a
> production web hosting server:
> - Laptop A: complete working copy.
> - Laptop B: complete working copy.
> - Local Server: complete working copy for backup and centralized
> repository.
> - Web Hosting Server: only the output folder content (or complete
> working copy, if we can´t send only the output folder).
> My question is how to setup the post-receive hook on local server to
> push the output folder to the web hosting server.
> I have been following some posts on the web. They all set local
> server as a bare repository, but I need it to host the complete
> project: source and output files. It seems to me that a bare
> repository can´t act as central repository for collaborators. Is it
> right?

OK, let's digest this piecemeal.

First, you appear to make a false connection between your "output"
directory and the type of the shared/public Git repository.
Git in either setup does now know about this directory -- that
knowledge belongs only in your static website generator.

Now what you really want to have is a way to check the files present in
some revision of interest to some place where Pelican can pick them up.
With a "normal" (non-bare) Git repository you get this sort of for free:
by means of having the work tree naturally coupled to the repository

But that's not required for having your files checked out.  90% of
random HOWTOs you're able to google using "git+web+deployment" explain
exactly this scenario: there's only a bare repository on the target
server, and the files from the tip commit among those just pushed
get checked out to some arbitrary directory.  Most of the time this is
done via environment variables, namely, GIT_DIR, GIT_WORK_TREE and
GIT_INDEX_FILE environment variables.  POSIX shell pseudocode for a
post-receive hook:

  set -e -u
  GIT_WORK_TREE=`mktemp -d /tmp/siteXXXXXXX`
  trap "rm -rf '$GIT_WORK_TREE'" TERM INT EXIT
  git read-tree master
  git checkout-tree -a
  pelican --srcdir="$GIT_WORK_TREE" --outdir /path/to/output/dir

The script rolls like this:
1) Sets GIT_DIR to the path of your repo.
2) Creates a temporary directory for the files to be checked out.
   And immediately arranges for it to be removed when the script
   is terminated or exits.
   The name of this directory is assigned to GIT_WORK_TREE.
2) Make up GIT_INDEX_FILE variable pointing to a non-existing
   file under our artifical work tree.  That's fine unless
   the name clashes with some existing file.
3) All these variables are then exported -- in order for the
   git programs called afterwards to see them.
4) The tip revision on "master" is read into the index.
5) The information from the index is checked out to the
   work tree.
6) Pelican runs.
7) The script exits and our temporary "work tree" gets deleted.

Sure, there are other ways to do this.  If your web site is huge,
you can make your work tree persistent and use the correct keys to
`git checkout-tree` to make it play well with the files already there.

One last note on hooks: the hook you want to use is supposedly
post-update, not post-receive.  An error in the latter kind of hook
aborts incorporating the history you've pushed while the former kind of
hook only runs when the repository's object database is updated.  Hence
post-receive is for "linting" -- where you might decide to fail pushing
for some reason, and post-update is for making use of the state just

Now let's move on to the "deployment" phase.
You have used the word "pushing" so it's unclear if you really mean
using Git to sync whatever Pelican generates with your production
While this is possible -- just turn Pelican's output directory into a
regular Git repository and use `git add -A` + `git commit` there after
Pelican finished running, -- IMO this needlessly complicates things and
I'd better use rsync (or unison or whatever) or git-ftp [1].

1. https://github.com/git-ftp/git-ftp

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to