2

I'm experiencing a weird problem, which I think might be a bug.

I pushed a change in the configuration to the Git server. This included a new repository, so after pushing I logged on to the server to create and initialize the repo (as a copy of the main product repo teamer.git):

rwel@ve-git:/home/git/repositories/teamer$ sudo su git
git@ve-git:~/repositories/teamer$ git clone --bare ../teamer.git analytics.git
git@ve-git:~/repositories/teamer$ gitolite setup

The weird thing is, running "gitolite setup" appears to have reverted my changes! In the repository, a new commit has appeared with exactly the previous state of the configuration:

GitX screen shot What has happened here and how can I fix it? If you need more info, please let me know.

Thanks!

Edit: I got some errors after pushing the new config, might have something to do with it:

gitolite-admin rwel$ git push origin
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 1.07 KiB, done.
Total 7 (delta 2), reused 0 (delta 0)
remote: *** hooks.mailinglist is not set so no email will be sent
remote: *** for refs/heads/master update 85dd4c5e7592fadbdb0d445a245a8763d6e2042b->1063acec3b106b348fadac655d154a78ea15ead5
remote: FATAL: no files/dirs called 'hooks' or 'logs' are allowed
Rijk
  • 11,032
  • 3
  • 30
  • 45
  • Why would you manually create a bare repo on the Gitolite server side? Declaring it in the `gitolite.conf` file of the `gitolite-admin` repo (and pushing that one) is enough to triggering the new repo creation. – VonC Nov 19 '12 at 12:08
  • Note: by looking at the picture, you are indeed pushing gitolite-admin, but I still don't see why you would have to create a bare repo your self on the Gitolite server. – VonC Nov 19 '12 at 12:20
  • @VonC: I know, but for some reason this did not happen. I did get some errors after the push (I'll add them to the post), maybe this had something to do with it. But I needed to create the repo manually anyway, as I need it to be a clone of another repo instead of a fresh one. – Rijk Nov 19 '12 at 13:04
  • "hooks.mailinglist is not set"? Do you have some hook like a git-commit-notice (http://anonscm.debian.org/git/pkg-gambas/git-commit-notice) in place for all repos? Gitolite doesn't install that, and if you need it, you would declare it as a VREF (http://stackoverflow.com/questions/10888300/gitosis-vs-gitolite/10888358#10888358), not a classic hook. – VonC Nov 19 '12 at 14:02
  • Yes, I've added a `post-receive` hook in `hooks/common`, that sends out notifications when one of my fellow developers pushes a new commit to his/her repo (so I know I need to evaluate the code and merge it in the develop branch). Is this not right? Strange, cause it was working perfectly.. – Rijk Nov 20 '12 at 08:15
  • With gitolite V3, you would declare any post-receive hook as a VREF. It could have side-effect with the `gitolite setup` command. – VonC Nov 20 '12 at 08:24

1 Answers1

2

I think I found the problem. I had my (common) hooks placed in the root directory of the Gitolite admin repository ([gitolite-admin.git]/hooks/common). Git does not like this, hence the error:

remote: FATAL: no files/dirs called 'hooks' or 'logs' are allowed

Probably because of this, my Gitolite install got messed up, with the setup script appearantly trying to revert the failed commit.

The fix

  1. First, I had to clean up the mess in the gitolite-admin.git repo by cloning it on the server, resetting it to HEAD^ and force-pushing that back to the repo (as explained here).

    git@ve-git:~/temp$ git reset --hard HEAD^
git@ve-git:~/temp$ gitolite push origin -f

  2. To fix the fatal error, I simply moved the hooks to a subdirectory, as advised in the documentation (in a branch based on the reset master from step 1):

    $ git checkout -b hooksfix origin/master
$ mkdir extra
$ mv hooks extra
$ git add --all
$ git commit -m "moved hooks directory to prevent errors"
$ git push origin hooksfix:master

    To make this work, I also had to add a line to the .gitolite.rc file on the Git server:

    LOCAL_CODE                  => "$ENV{HOME}/.gitolite/extra",

  3. After pushing this, the fatal error was gone. I then proceeded to rebase my initial change on the fixed master, and could now also push that with no problems.

    $ git checkout master
$ git rebase origin/master
$ git push origin
Rijk
  • 11,032
  • 3
  • 30
  • 45
  • My gitolite installation script takes advantage of the `LOCAL_CODE` variable to isolate any hook/VREF in its own separate directory: https://github.com/VonC/compileEverything/blob/master/gitolite/install_or_update_gitolite.sh – VonC Nov 20 '12 at 09:56