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 init --bare

And added the following hook:

$ mkdir /var/www/example.com
$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/example.com git checkout -f
$ chmod +x hooks/post-receive

when I push to website.git from local repository, the update works fine. But no files are added into /var/www/example.com. How can I investigate what could be wrong here? Any kind of log or something?

EDIT ----------------------

The problem is fixed if I push to master branch on repoRemote, not demo. Why is so?

Answer 1

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 2

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 3

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

Answer 4

I do this on my sites:

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

Answer 5

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 6

Make the script executable:

chmod +x .git/hooks/post-receive