git post-receive hook 无法跳回到原来的cwd
当推送到我们的共享裸存储库(通过 ssh)时,提交后无法正常工作。
正如我在此处的许多线程中发现的那样,这很常见,并且对于同一服务器上的其他两个存储库来说它工作得很好,这让我发疯。
#!/bin/sh
GIT_WORK_TREE=/ab/cd/staging git checkout -f
存储库本身与挂钩应签出的目录位于同一目录中。
/ab/cd/barerepo
推送时,它不会将文件签出到预期路径,但会给出此错误消息:
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
我找不到有关这意味着什么的任何信息。 (据我所知,Google 只提出对 git 本身的贡献)。所以我阅读、猜测并尝试...
- 另外在接收后钩子中设置 GIT_DIR
- 重新初始化裸存储库,使用 --git-dir=/ab/cd/barerepo --working-dir=/ab/cd/staging
- 设置工作目录在 barerepo/config 中手动
- 设置裸存储库空白并
- 通过克隆提交设置裸存储库
现在配置看起来像这样,
[core]
repositoryformatversion = 0
filemode = true
bare = true
但我也有这个(不费力)
[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 1
worktree = /ab/cd/staging
logallrefupdates = true
[receive]
denyNonFastforwards = true
我还在post-receive hook
echo "post-receive done" > updated.txt
它将文件写入裸存储库的目录。这对我来说很有意义,因为 GIT_DIR 似乎被设置为“.”,这是由我从另一个 SO 问题得到的接收后剪裁所确认的
echo Running $BASH_SOURCE
set | egrep GIT
echo PWD is $PWD
结果:
Running hooks/post-receive
GIT_DIR=.
PWD is /ab/cd/barerepo
那么我怎样才能让 git 跳回到原来的 cwd (当前工作)目录?)? 仅供参考:我对 git 还很陌生,有一种愚蠢的感觉,我错过了一些明显的东西,但没有找到关于这个特定错误消息的任何重要信息让我感到好奇。顺便说一句,推送本身效果很好。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我在同一台服务器上托管的十个站点中也遇到过此问题。
每个站点在 Web 服务器上都有一个裸存储库(未暴露在 Web 上),我们的开发人员将向其推送该存储库。和您一样,我们使用 git post-receive 挂钩,然后将
GIT_WORK_TREE=/whatever/livesite git checkout -f
放入包含实际 Web 服务器根目录的目录中。检查以
fatal: Could not Jump back into original cwd
失败的那个有什么不同,我发现在所有工作情况下,存储库名称都是这样的:出错的一个是这样的:
所以让实时签出的副本具有这样的名称会导致 git 抛出此错误。将实时站点工作副本存储库的名称更改为以“.wtf”结尾解决了问题(我最终像其他人一样使用了“.live”)。
在我的例子中,Git 的服务器版本是 1.6.1,而开发机器都是 1.7.5.4。
因此,bare repo 和 live repo 的名称似乎有影响。不确定这是否是 git 中的错误,或者只是“foo”和“foo.git”的一些神奇等价物的副作用。
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:The one erroring out was like this:
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.
根据我的经验,您的问题在于您的 .git 存储库和工作树目录(您的 post-receive 挂钩正在检出)位于同一目录中:ab/cd。
我也是 GIT 新手,这篇文章对我帮助很大,所以谢谢!消除了您已经尝试过的所有修复后,我在某个地方偶然发现了一篇文章(恐怕我现在找不到它),它读取 .git 存储库,并且工作树目录不能位于同一目录中。
我不知道为什么。
例如,您的 /var/www 中有 /staging/ 目录。这意味着您应该将裸露的 .git 存储库放在 /var/GIT (或其他东西)中,而不是 /var/www 中。
我遇到的另一个问题是权限,因此我对两个目录进行了 chown 和 chmod,以确保我推送的远程用户有权读取/写入这两个目录。
不管怎样,我这样做了,我从你所在的地方得到了这个:
那个和一个很好的胖检查目录充满了代码:)
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:
That and a nice fat checking out directory full of code :)
服务器更新到 git v1.7.5.4 后问题就消失了。看来从 v1.5x(服务器)到 1.7x(本地)的差异太大了。
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.