Why does `rm -rf` behave differently when used in a git post-receive hook as opposed to shell?
The hook pretty much clones the bare repo into a temporary directory, and after generating the site, removes that temporary git clone.
#!/bin/sh # clone a repo, generate site etc # done generating site, remove the TMP_GIT_CLONE rm -rf $TMP_GIT_CLONE
When I do the push, all the other tasks fine, but doesn't remove all the files.
I get the follwing errors:
remote: rm: <TMP_GIT_CLONE>/.git/objects/pack: Directory not empty remote: rm: <TMP_GIT_CLONE>/.git/objects: Directory not emppty
You get the idea
However, when I invoke the post-receive script directly from the command line, the rm behaves as expected.
Note: I've looked at Post-hook receive act's differently to shell, where the asker's problem had to do with being in a bare repo instead of a work-tree.
to get rm's path eg. /bin/rm
then replace it with /bin/rm to get another try. Sometimes, it is occurs by your shell script's start scripts.
I don't know if you ever found a way around this, but I had the exact same problem. I found that the /git/objects/pack directory was the one not emptying. I suspect that whatever process is used to track files runs slower or in a different manner when you're either in ssh or post-receive.
One way is to manually remove those directories. This kind of worked for me, but I didn't want to depend on that structure being the same. I tried removing just the .git directory first. That produced the odd behavior of complaining about non-empty directories but eventually emptying them.
A better approach is to avoid the unnecessary git files in the first place. The answers to this question may provide some insight. I replaced the 'git clone' line with:
mkdir -p $TMP_GIT_CLONE git archive master --format=tar | tar -x -f - -C $TMP_GIT_CLONE
I think it's safe to git rid of $GIT_REPO. Since you're in a post-receive hook, you know you're in the repo you want to clone anyway.