post-receive hook fails - any chance to see why?

Question

I\'m implementing this approach to send updates to my website:

created bare repository to push to

$ mkdir website.git && cd website.git
$ git         


        

Answer 1

Make the script executable:

chmod +x .git/hooks/post-receive

Answer 2

I do this on my sites:

#!/bin/sh
unset $(git rev-parse --local-env-vars)
cd /var/www/example.com
git pull

Answer 3

Another possible cause for post-receive hook trouble is identified and fixed in Git 2.13 (Q2 2017): if the GIT_WORK_TREE is set to an invalid path.

See commit ce83ead, commit aac3eaa (08 Mar 2017) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit ba37c92, 13 Mar 2017)}

Example (which would crash with Git 2.12 only)

GIT_WORK_TREE=/.invalid/work/tree &&
export GIT_WORK_TREE &&
git rev-parse
# dies with error code 128

The bug was introduced in Git 2.12.

Answer 4

cd .git/hooks
mv post-receive post-receive-inner

now create a new post-receive:

#!/bin/bash
set -x
./post-receive-inner "$@" 1>/tmp/git.log 2>&1 

Make this executable and try again, the results should end up in /tmp/git.log

Answer 5

Edit, Dec 2016: people are still finding this old answer, and now, 3 years later, I truly understand what the real issue is. The problem occurs when you use a post-receive hook to deploy multiple different branches. If you only ever deploy one branch from a bare repository, you will have fewer problems. Git keeps evolving and the "best" solution for automatic deployment of several branches may vary depending on which Git version you have. See also Git post-receive deployment stops working at random points.

(Original answer below line.)

---

I've found that git checkout -f always needs a branch name; allowing it to use HEAD in bare repositories is not very predictable.

You may also run into issues with the index (git will write one in the bare repo, but it gets confused at times). It works best to git checkout -f deployment-branch into a new, fresh, empty directory. (It should work to set an index file per deployment-branch, I've just never gotten around to experimenting with this.)

If your bare repo will be fairly active on other branches than the one(s) used for deployment, it's a good idea to wrap the code with fancier shell-scripting that checks whether the deployment branch in question has actually been changed. That is, if someone updates web-devel, there's no point re-re-re-deploying deployment-branch, which they did not update this time.

Answer 6

From comments above about reliability of targeting specific branches - I found this gist which targets the master branch from post-receive hook.

#!/bin/bash 
set -eu

TARGET="/deployment-location-here"
GIT_DIR="/trigger-location-here"
BRANCH="master"

while read oldrev newrev ref
do
        # only checking out the master (or whatever branch you would like to deploy)
        if [[ $ref = refs/heads/"$BRANCH" ]];
        then
                echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
                git --work-tree="$TARGET" --git-dir="$GIT_DIR" checkout -f
        else
                echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
        fi
done