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.

Reply via email to