git post-receive hook 无法跳回原来的cwd

Question

当推送到我们的共享裸存储库(通过 ssh)时，提交后无法正常工作。
这很常见，因为我在这里的许多线程中都发现了它，并且它适用于同一服务器上的其他两个存储库，这让我发疯。

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

存储库本身与 Hook 应 check out 的目录位于同一目录中

/ab/cd/barerepo

推送时，它不会将文件 check out 到预期路径，而是给出此错误消息:

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

我找不到任何关于这意味着什么的信息。 (据我所知，谷歌只提出来自对 git 本身的贡献的提交)。所以我阅读、猜测和尝试……

• 另外在接收后 Hook 中设置 GIT_DIR
• 使用 --git-dir=/ab/cd/barerepo --working-dir=/ab/cd/staging 重新初始化裸仓库
• 在 barerepo/config 中手动设置工作目录
• 设置裸 repo 空白并提交
• 通过克隆设置裸仓库

现在的配置是这样的

[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

我还在接收后 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 还是很陌生，并且有一种愚蠢的感觉，我错过了一些明显的东西，但是没有找到关于这个特定错误消息的任何必要内容让我感到奇怪。推送本身工作正常，顺便说一句。

Answer 1

在同一台服务器上托管的十分之一的站点中，我也遇到过此问题。

每个网站在我们的开发者推送的网络服务器上都有一个裸仓库(不暴露在网络上)。与您一样，我们使用 git post-receive Hook 将 GIT_WORK_TREE=/whatever/livesite git checkout -f 放入包含实际 Web 服务器根目录的目录中。

检查失败的fatal: Could not jump back into original cwd 有什么不同，我看到在所有工作情况下，存储库名称都是这样的:

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

出错的是这样的:

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

所以让实时 checkout 的副本有一个这样的名字导致 git 抛出这个错误。将实时站点工作副本存储库的名称更改为以“.wtf”结尾解决了这个问题(我最终只是像其他人一样使用“.live”)。

在我的例子中，Git 的服务器版本是 1.6.1，而开发机器都是 1.7.5.4。

所以 bare repo 和 live repo 的名称似乎有影响。不确定这是 git 中的错误，还是只是“foo”和“foo.git”的某些神奇等价物的副作用。