4

I'm using this example on publishing a website w/ git post receive hooks.

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.

Why?

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.

Community
  • 1
  • 1
Derrick
  • 2,356
  • 5
  • 32
  • 43
  • Some ideas: you are using another version of `rm`, or another shell which has a built-in `rm` command? – Paŭlo Ebermann May 31 '11 at 18:44
  • I'm inclined to say that the environments are the same. `which -a rm` only returns one (logged in). It's on FreeBSD 7.2 (nearlyfreespeech). Login shell is bash. my `.bash_profile` gets executed on login, as well as with the git post receive hook – Derrick Jun 01 '11 at 01:43
  • add some 'ls -a' commands after the rm to see what files are sticking around. that might give you some clues. – Frosty Jun 21 '11 at 15:16
  • any file that is a directory stays around – Derrick Jun 23 '11 at 07:26
  • What is your umask set to? What user owns that directory? What are the permissions on the directory you are cloning into? – X-Istence Jun 23 '11 at 19:43
  • Still you should check these things from the Gig script also. It might execute wita a different environment from yours (different PATH, different umask, ... in the general case even on a different host) so only checking from your interactive shell is not sufficient. (Pardon if I am stating the obvious; it is not clear from your comments whether you have done this already.) – tripleee Aug 07 '11 at 18:13
  • 1
    No, need for pardon, I haven't done all these things from a non-interactive shell. I'll report back when I've checked these things out – Derrick Aug 13 '11 at 06:20

2 Answers2

1

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.

The solutions:

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.

Community
  • 1
  • 1
1

use

which rm

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.

Daniel YC Lin
  • 15,050
  • 18
  • 63
  • 96
  • Hi, thanks for your answer. Can you explain the reasoning behind this in more detail? My PATH works correctly, because the actual *launching* of executables work fine (e.g. `jekyll`, `rm`, etc). The thing is that `rm` seems to only be removing some files, but not all of them. It's as if the -rf options are not sticking, or the permissions are different. – Derrick Nov 03 '11 at 18:23
  • It depends on your shell. For example, if you use bash and the system have some default "alias". You could check `alias rm`. Does my solution work? – Daniel YC Lin Nov 04 '11 at 07:35