I learned a lot about git usage from you, so thanks for your suggestions & help!
I tried your suggestions, and found no additional error message, which can explain why the working dir is not updated. BUT: you wrote, that the working dir is updated only, when there was at least one change in local repo, it was committed, then I push to the git bare repo on the server. Yeah, it seems, this was the cause why the working dir was not updated. I tried the post-update hook, too, but no difference. My problems: 1) Basically I would like to update the working dir, when I do a git push to the server. Is it possible? 2) My second problem, what happens, when I delete a file from the local repo? Is it also deleted from the working dir? So git checkout -f does a copy (which leaves deleted files in target dir)? or does a mirror (which deletes the deleted files from target dir, so will always have exactly the same content )? Basically I would need mirroring. Any ideas for these 2 problems? Thanks is advance, Konrad Lorinczi 2015. április 24., péntek 21:42:47 UTC+2 időpontban Konstantin Khomoutov a következőt írta: > > On Fri, 24 Apr 2015 11:59:33 -0700 (PDT) > Konrád Lőrinczi <klor...@gmail.com <javascript:>> 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.
