git post-receive hook can not jump back into original cwd

Question

When pushing to our shared bare repository (over ssh), the post-commit does not work properly.
It is pretty common as I found out in many threads here and it works fine for two other repositories on the same server, which drives me insane.

#!/bin/sh
GIT_WORK_TREE=/ab/cd/staging git checkout -f

The repository itself is in the same directory as the directory the hook shall checkout to

/ab/cd/barerepo

When pushing, it does not check out the files to the intended path, but gives this error message:

Writing objects: 100% (3/3), 299 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
fatal: Could not jump back into original cwd
error: hooks/post-receive exited with error code 128

I could not find any information about what this means. (Google only brings up commits from the contribution to git itself, as long as I can tell). So I read and guessed and tried …

• additionally setting GIT_DIR in post-receive hook
• re-initializing bare repo with --git-dir=/ab/cd/barerepo --working-dir=/ab/cd/staging
• setting the working directory manually in barerepo/config
• setting up the bare repo blank and committing
• setting up the bare repo by cloning

Right now the config looks like this

[core]
     repositoryformatversion = 0
     filemode = true
     bare = true

but I also had this (to no effort)

[core]
    repositoryformatversion = 0
    filemode = true
    bare = true
    sharedrepository = 1
    worktree = /ab/cd/staging
    logallrefupdates = true
[receive]
    denyNonFastforwards = true

I also added a second line to the post-receive hook

echo "post-receive done" > updated.txt

It writes the file to the directory of the bare repository. This makes sense to me, since GIT_DIR seems to be set to '.', which is confirmed by a post-receive snipped I got from another SO question

echo Running $BASH_SOURCE
set | egrep GIT
echo PWD is $PWD

Result:

Running hooks/post-receive
GIT_DIR=.
PWD is /ab/cd/barerepo

So how can I bring git to jump back to the original cwd (current working directory?)? FYI: I'm still pretty new to git and have a dumb feeling that I'm missing something obvious, but not finding anything essential about this particular error message makes me wonder. The push itself works fine, btw.

Joshi

Are the permissions correct on the staging directory for this repository? That is, are they the same as they are for the repos that work? – Stung

Yes, the staging directories both have drwxrwxr-x, same user and same group (gitusers). The users pushing into the repo are also members of this group. The subdirectories inside the repositories have drwxrwsr-x so that the group stays gitusers when users push their commits. – Joshi

Answer 1

After the server was updated to git v1.7.5.4 the problem was gone. Seems that the discrepancy from v1.5x (Server) to 1.7x (local) was too much.

Joshi

Answer 2

I also experienced this problem for one site out of ten, hosted on the same server.

Each site has a bare repo on the web server (not exposed to the web) to which our develpoers push. Like you, we use a git post-receive hook to then GIT_WORK_TREE=/whatever/livesite git checkout -f into the directory that contains the actual web server root.

Examining what was different about the one that failed with fatal: Could not jump back into original cwd, I saw that in all the working cases, the repository names were like this:

/var/www/coolsite.com.git   <-- bare repo
/var/www/coolsite.com.live  <-- checked out from hook; contains site root in public subdir

The one erroring out was like this:

/var/www/brokensite.com.git  <-- bare repo
/var/www/brokensite.com      <-- checked out from hook; contains site root in public subdir

So having the live checked out copy have a name like that caused git to throw this error. Changing the name of the live site working copy repo to end with '.wtf' fixed the problem (I eventually just used '.live' like the others).

In my case the server version of Git is 1.6.1 while the dev machines are all 1.7.5.4.

So the name of the bare repo and the live repo seem to have an impact. Not sure if this is a bug in git or just a side effect of some of the magic equivalency of 'foo' and 'foo.git.

Renny

For those searching out there, this fixed my problem as well. – Jemappes

Fixed it for me. Summary: the checked-out repo can't have the same directory name as the bare repo (with the only difference being the .git dirname suffix). Change the name of one or the other. Thanks! – Meshwork

Werid. It fails if the work dir is any substring of the bare repo, e.g. $HOME/www and $HOME/www-repo – Cosgrove

Had this exact same issue (fixed by the above solution). Would not expect this at all, is this perhaps a .git bug? – Halvah

Answer 3

From my experience, your problem lies in that you have your .git repository and your working tree directory (to which your post-receive hook is checking out) in the same directory: ab/cd.

I'm new to GIT, also, and this post helped me out a lot, so thanks! Having eliminated all the fixes you'd already tried, I stumbled across a post somewhere (I'm afraid I can't find it now) that read the .git repository and the working tree directory cannot be in the same directory.

I know not why.

So e.g., you have your /staging/ directory in your /var/www. This would mean you should put your bare .git repository in /var/GIT (or something), not /var/www.

Another problem I had was permissions, so I chown'ed and chmod'ed both directories to ensure the remote user I was pushing with had permission to read/write to both directories.

Anyway, I did this and I got from where you were to this:

Counting objects: 3357, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2848/2848), done.
Writing objects: 100% (3057/3057), 15.20 MiB | 4.70 MiB/s, done.
Total 3057 (delta 1536), reused 0 (delta 0)
Checking out files: 100% (3720/3720), done.
To ssh://xxxxxx@xxxxxxxxxxxxxxx/var/GIT/project.git
   945fe94..dbe1f0b  master -> master

That and a nice fat checking out directory full of code :)

Myriagram

Our root of our problem could not really be the same base directory, since that works for other repositories, too. – Joshi

Exactly!!! I took half a day to debug it. Some pointers. It only happens on a hook and not directly. Put export PATH=$PATH:"/usr/local/ in to make sure git command is available. Put exec &>> $LOGFILE capture the error message from you git command. – Hiawatha