为什么在git post-receive钩子中使用`rm -rf`而不是在外壳上时会有不同的表现？

如何解决为什么在git post-receive钩子中使用`rm -rf`而不是在外壳上时会有不同的表现？

| 我在发布带有git post接收钩子的网站上使用此示例。 该挂钩几乎将裸仓库克隆到一个临时目录中，并在生成站点后删除该临时git克隆。

#!/bin/sh
# clone a repo,generate site etc
# done generating site,remove the TMP_GIT_CLONE
rm -rf $TMP_GIT_CLONE

当我执行推送时，所有其他任务都可以，但不会删除所有文件。 我收到以下错误：

remote: rm: <TMP_GIT_CLONE>/.git/objects/pack: Directory not empty
remote: rm: <TMP_GIT_CLONE>/.git/objects: Directory not emppty

... 你明白了 但是，当我直接从命令行调用

post-receive

脚本时，

rm

的行为符合预期。 为什么？ 注意：我看过挂机后接收行为与shell有所不同，在这种情况下，发问者的问题与放入裸仓库而不是工作树有关。     

解决方法

        采用

which rm

获得rm的路径，例如。 / bin / rm 然后将其替换为/ bin / rm以再次尝试。有时，它是由Shell脚本的启动脚本引起的。     ,        我不知道您是否找到解决此问题的方法，但是我遇到了完全相同的问题。我发现/ git / objects / pack目录是不清空的目录。我怀疑无论是使用ssh还是接收后，用于跟踪文件的任何过程都会运行缓慢或以不同的方式运行。 解决方案： 一种方法是手动删除那些目录。这种方法对我有用，但是我不想依赖于相同的结构。我尝试先删除.git目录。这产生了抱怨非空目录但最终清空它们的奇怪行为。 更好的方法是首先避免不必要的git文件。答案 这个问题可能会提供一些见识。 我将\'git clone \'行替换为：

mkdir -p $TMP_GIT_CLONE
git archive master --format=tar | tar -x -f - -C $TMP_GIT_CLONE

我认为git $ REP_REPO是安全的。由于您处于接收后挂接状态，因此您知道自己仍在要克隆的存储库中。