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

发布于 2024-11-19 13:34:38 字数 1623 浏览 1 评论 0原文

当推送到我们的共享裸存储库(通过 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

背叛残局 2024-11-26 13:34:38

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

每个站点在 Web 服务器上都有一个裸存储库(未暴露在 Web 上),我们的开发人员将向其推送该存储库。和您一样,我们使用 git post-receive 挂钩,然后将 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

所以让实时签出的副本具有这样的名称会导致 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:

/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.

拍不死你 2024-11-26 13:34:38

根据我的经验,您的问题在于您的 .git 存储库和工作树目录(您的 post-receive 挂钩正在检出)位于同一目录中:ab/cd。

我也是 GIT 新手,这篇文章对我帮助很大,所以谢谢!消除了您已经尝试过的所有修复后,我在某个地方偶然发现了一篇文章(恐怕我现在找不到它),它读取 .git 存储库,并且工作树目录不能位于同一目录中。

我不知道为什么。

例如,您的 /var/www 中有 /staging/ 目录。这意味着您应该将裸露的 .git 存储库放在 /var/GIT (或其他东西)中,而不是 /var/www 中。

我遇到的另一个问题是权限,因此我对两个目录进行了 chown 和 chmod,以确保我推送的远程用户有权读取/写入这两个目录。

不管怎样,我这样做了,我从你所在的地方得到了这个:

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

那个和一个很好的胖检查目录充满了代码:)

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 :)

惯饮孤独 2024-11-26 13:34:38

服务器更新到 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文