One of the things I love about git is how easy it makes website deployment. Stick all your versions (production, development, test, yadda yadda) in different branches, push to a bare repo on the server, and set up your post-receive hook to put the right versions in the right places by checking out individual branches to different working directories. Bam, done.

I would have set up pelican the same way, except I want to be able to make changes directly on the server. Technically, what I should have done is create the bare master repo, point the detached checkout to wherever I want the live site, and make a separate local clone as my on-server work area. (Really pelican content isn't live, per se, but it generates the static files that are, so close enough.):

• Master repo: /path/to/pelican-master.git
• Work area: /path/to/pelican-work
• Live area for detached checkout: /path/to/pelican-live

What I did instead was create the on-server work area (the local clone) where the detached checkout would normally be:

• Master repo: /path/to/pelican-master.git
• Work area: /path/to/pelican-live
• Live area for detached checkout: same as the work area!

Seemed like a good idea at the time, because it cut down on random arbitrary directories of zillions of copies of the same files all over the place, but I broke the whole detached checkout idea. If pelican-live is already a repo, I can't really use it as the detached working directory for the master repo. My clean and clear post-receive hook is now an unholy hash of checkout -f/fetch/reset nonsense:

if [ "master" == "$branch" ]; then
    cd $pelicanweb
    git checkout -fq $branch && git fetch && git reset --hard origin/$branch
    if [ $? -ne 0 ]; then
        echo 'git broke, go check the configs or something'
        exit 1
    fi

    make html && echo 'Changes live'
fi

On the other hand, it's working, and I want to go play with CSS.