Question

We’re using git with a central repo (using Gitosis). I’ve created a post-receive hook to generate an email to the dev mailing list whenever changes are pushed to the central repo, and to generate documentation from the documentation folder in the git repo.

Therefore, in ~git/ I’ve got a directory, we’ll call it ‘a’ that contains a clone of the git repo. The post-receive hook looks like:

#!/bin/bash
cd ~git/repositories/a.git
. ~git/post-receive-email &> /dev/null
( cd ~git/a && git pull &> ~git/pull_log.log && php ~git/a/scripts/generate_markdown_documentation.php &> ~git/doc_log.log )

The email script is working, but the documentation generation is not. The content of pull_log.log is:

fatal: Not a git repository: '.'

Which makes me think that it’s not changing to the correct directory in line 5 of the above script. Am I wrong? How can I get this to work?

Edit: I’ve updated the post-receive hook as suggested in the responses. The script is now:

#!/bin/bash
function die {
  echo "$*" >&2; exit 1
}

function checkgit {
  [ -d "$1/.git" ] || die "$1 could not possibly be a git repo; $1/.git is not a dir"
}


cd ~git/repositories/a.git
. ~git/post-receive-email &> /dev/null
( set -x
checkgit ~git/a
cd ~git/a
checkgit .
pwd
git pull
php ~git/a/scripts/generate_markdown_documentation.php )

And I get the following output from git push:

+ checkgit /var/git/a
+ '[' -d /var/git/a/.git ']'
+ cd /var/git/a
+ checkgit .
+ '[' -d ./.git ']'
+ pwd
/var/git/a
+ git pull
fatal: Not a git repository: '.'
+ php /var/git/a/scripts/generate_markdown_documentation.php

Any more help?

Oh, and if I run the script myself, it works (I run it by saying hooks/post-receive)

Discovered the problem, thanks to serverfault — basically, environment variables GIT_DIR and GIT_WORK_TREE are set when the hook runs, and these affect git pull adversely. Unsetting the variables fixes the problem.

Answer 1

You need more diagnostics, e.g.,

function die {
  echo "$*" >&2; exit 1
}

function checkgit {
  [ -d "$1/.git" ] || die "$1 could not possibly be a git repo; $1/.git is not a dir"
}

At this point, in the subshell right after the parenthesis, you can try stuff like

set -x # show exactly what's executed (writes to stderr)
checkgit ~git/a
cd ~git/a && checkgit . && git pull ...

You might also consider redirecting the whole stderr of the subshell, e.g.,

( ... ) 2>/tmp/mydiagnosis$$.log

(This is a temporary measure and is OK only if there’s no confidential info in the logs.)

---

OK Silas, your additional info rules out a lot of awkward possibilities. I’m nearing the end of my git fu, but here are some more things to try:

1. Go into ~git/a and see if you can make it git pull by hand. This should fail.
2. Got into ~git/a and run git status. This should also fail. If it doesn’t, then git is giving you a very bad error message.

If both steps fail, ~git/a is not the clone you thought it was. Rename it, make a new clone, and see if you can get the problem to persist.

If the first step succeeds by hand, then something strange is going on and I’m baffled.

If the first step fails but the second succeeds, you may have a problem with branches:

• Perhaps repo ~git/a is set to the wrong branch, and your repo needs a branch it doesn’t have. Try git branch -a and see if you see something unexpected.

• Perhaps you have the branch, but it’s not properly associated with a remote repository. At this point you have to dive into ~git/a/.git/config, and I don’t really know how to explain what you should expect to find there. At that point you will need a real git expert; I just play one on TV.