Thank you for your answer. I am now studying all you said.

I am sorry I forgot to say previously that Pelican runs on the 
collaborators laptops. The versioned folder already includes source, 
output, and other sub-folders and files. The workflow: our collaborator 
will edit the source files; run pelican to generate the output files; 
verify the output files using a browser; and, after confirm everything is 
OK, he/she will commit the changes and push them to our local server 

We need to version control and store on the local server the files already 
available on the laptops.

What we are looking for is a way to copy one of the versioned sub-folders 
(named output) from local server (origin) to another server (webhosting), 
making use of post-update, when origin is updated.

Git , version control, and english, are still a bit mysterious to me and 
sometimes I can´t find the words. I hope you understand.


Em terça-feira, 2 de junho de 2015 12:09:58 UTC-3, Konstantin Khomoutov 
> On Tue, 2 Jun 2015 07:26:54 -0700 (PDT) 
> Márcio Moreira <mar...@verdesaine.net <javascript:>> 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 
> itself. 
> 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: 
> ---8<--- 
>   #!/bin/sh 
>   set -e -u 
>   GIT_DIR=/path/to/your/repo/on/the/server 
>   GIT_WORK_TREE=`mktemp -d /tmp/siteXXXXXXX` 
>   trap "rm -rf '$GIT_WORK_TREE'" TERM INT EXIT 
>   GIT_INDEX_FILE="$GIT_WORK_TREE/.gitindex" 
>   git read-tree master 
>   git checkout-tree -a 
>   pelican --srcdir="$GIT_WORK_TREE" --outdir /path/to/output/dir 
> ---8<--- 
> 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 
> pushed. 
> 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 
> server. 
> 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