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 …
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.
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.
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 :)
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With