On Fri, 24 Apr 2015 11:59:33 -0700 (PDT) Konrád Lőrinczi <klorin...@gmail.com> wrote:
[...] > mkdir /domains/git/site-bare.git > cd /domains/git/site-bare.git > git --git-dir=. --work-tree=/domains/site/test-workdir/. init > git config receive.denycurrentbranch ignore > cd /domains/git/site-bare.git/hooks > nano post-receive > # add the following content until # end > #!/bin/sh > export GIT_WORK_TREE=/domains/site/test-workdir/. > export GIT_DIR=/domains/git/site-bare.git/.git ^^^ This. The GIT_DIR environment variable tells Git where the "Git database directory" is located. But a bare Git repo *is* the Git database directory in itself. That makes it different from a "normal" Git repository, in which the root directory is the so-called work tree, and the Git database directory is typically located beneath and called ".git". Obviously, in a bare repo, there's no ".git" subdirectory. Bare repos even typically have the ".git" suffix appended to their names precisely to signify they already are ".git directories". [...] > git push web-remote master > > > Once I also got the [...] > remote: fatal: Not a git repository: > '/domains/git/site-bare.git/.git' That most probably was the message a Git program run from your hook script yelled at you. Since you did not enable/provide proper error reporting in your hook script, even though `git checkout` failed with that error message, the script continued to chug along and hence the receive operation succeeded. [...] > Later I did not get such "Not a git repository" error. Did the hook run? If you had no new commits to push, the hook was not run. > But anyway, the workdir is not filled with content, this is my > problem. > > UPDATE: If I do "git checkout -f" of the server, then the workdir is > updated. So this means that the post-receive hook is not executed. > > Any idea why the remote workdir is not updated? There are many issues with your approach. The first one is that your GIT_DIR setting is incorrect (and outright nonsensical) as I expained above. But I'd say it is not needed at all: when the hook runs, it already has all the Git-related settings in its environment. So you only has to provide it with the location of your work tree. The second problem is that the hook is supposed to fail (that is, to exit with a non-zero exit code; supposedly having printed out an error message to the standard error stream before doing that) as soon as it encounters an error. In your case I'd start with placing the line set -e -u somewhere right after the shebang line (that #!/bin/sh thing). This would ask the shell to crash and burn as soon as any command it executed failed (and that was not properly handled by the script) or the script attempts to dereference a variable which was not assigned a value. I would also say that the correct event for the hook like yours is post-update, not post-receive. Receiving deals with, well, receiving, while post-update means the heads (branches) were already updated with their new commits. And another pro-tip. If you need to debug a script, running non-interactively, a useful "trick" is to wrap it in another script, something like this: #!/bin/sh set -e -u orig="`dirname '$0'`/post-update.orig" exec /bin/sh -x "$orig" $@ >/var/tmp/my-hook-trace.log 2>&1 Where your post-update.orig is the original script to debug, and the script I showed is temporarily made the post-update hook. The "-x" command-line option instructs the shell to trace the execution of the script it's told to run, and that trace ends up in the log file -- with all the diagnostic and error messages. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.