Gitolite and Non-Bare Repos

Gitolite and non-bare repos?

inotifywait waits for changes to files.

If you want to monitor changes at the server level (where gitolite operates, behind ssh), you will need to add a non-update hook, typically a post-receive one, which will checkout the bare repo somewhere monitored by inotifywait.

How to synchronize 2 bare repositories in Gitolite?

Certainly adding a post-receive hook (see "(v3.6+) variation: repo-specific hooks") is the easiest way.

cd /path/to/your/gitolite-admin-clone
mkdir -p local/hooks/repoA

git push --mirror ../repoB

Mirroring is mainly for synchronization between different gitolite servers (I suppose it could be setup to mirror on the same server as in t/mirror-test, but that it a bit overkill).

Plus it adds:

From v3.5.3 on, gitolite uses an asynchronous push to the slaves, so that the main push returns immediately, without waiting for the slave pushes to complete.

Keep this in mind if you're writing scripts that do a push, and then read one of the slaves immediately -- you will need to add a few seconds of sleep in your script.

That means:

If you have multiple gitolite servers to maintain, then mirroring is interesting, mainly because the push --mirror is done asynchronously from the initial git push to repoA.

In that aspect, gitolite mirroring is quicker, because you push to A, and in the background, gitolite will push --mirror to other gitolite servers.

But here, for just one other repo (on the same gitolite server, or on another gitolite server), a simple post-receive hook is enough.

Gitolite denies access to a repo while allowing another

While Windows is not case sensitive, Gitolite is, testing for the existence of the bare repo folder (see lib/Gitolite/Conf/Load.pm#L245-L250).

or you mis-spelled the reponame

If the gitolite.conf file allows access for OpenTK-10Bit-test, trying to clone OpenTk-10Bit-test (as commented by And) will not work and will be denied.

Cannot find my project files on the server gitolite is running

Gitolite operates with bare repositories.

A bare repo has no working tree, meaning no files.

That is why, by the way, your repo root directory ends with .git: it is a naming convention to reference bare repos.

See "Git push only for bare repositories?" for more.

Your repos are managed by default on:

~git/repositories/myrepo1.git
~git/repositories/myrepo2.git

Generally, you don't need to look to the content of a repo while being on the server: you simply clone it on a client and look it there. (the clone won't be a bare repo by default)

You could clone it on the server, if you have a proper ~git/.ssh/id_rsa(.pub) key declared as a user in the gitolite.conf file.

It is what I do, as a test, after installing/updating gitolite on my server.

That works because of my local ssh config file:

Host gitolitesrv
Hostname localhost
User @USERNAME@
Port @PORT_SSHD@
IdentityFile @H@/.ssh/gitoliteadm

So I have a ~git/.ssh/gitolite(.pub) private and public key dedicated to gitolite admin, which I can use locally on the server to clone gitolite repo if I want.

That is because I use that same key to setup gitolite:

 GITOLITE_HTTP_HOME= gitolite setup -pk "${H}/.ssh/gitoliteadm.pub"

If you have a similar setup, you can then clone any repo on the server:

git clone gitolitesrv:gitolite-admin "${gtl}/ga"

Can gitolite have repo and a clone of the same repo with different branches and, therefore, in effect have read access on per branch level?

I have this:

repo    dotfiles
    RW+CD @dev              = @ben.boeckel
    RW    refs/heads/master = @ben.boeckel
repo    priv/dotfiles
    RW+C refs/heads/non-public  = @ben.boeckel
    RW+C refs/heads/$hostname   = @ben.boeckel
    -                           = @all
    config gitolite-options.deny-repo = 1
    config core.sharedRepository = 0700

Where the $hostname line is repeated for each host-specific branch I have. This effectively ensures that any non-dev/ branch (the @dev) other than master is accessible is denied. The private repo is then locked down to just those branches.

The repositories are served over git-daemon and cgit in different jails which do not have user access to the repositories (and are mounted using ro and nullfs, so if the deny-repo option ever fails, the filesystem will deny the access as a failsafe.

Is there a way to diagnose why git init --bare doesn't create specific directories?

It is as if, on your server, the template used for creating a new repo has an incomplete content (ie one without hooks)

That template folder would be in <git>/share/git-core/templates, with <git> being the installation folder (on Windows ./mingw64/share/git-core/templates, on Linux, /usr/share/git-core/templates)

The lack of hooks can be intentional on a server which does not want any hook executed on it for security reason. (For instance, you cannot add hooks to a GitHub bare repo)

Redmine + Gitolite - Issue with repository permissions and more

I managed to get it working pointing the original repo to Redmine, since both sit on the same machine, by following some simple steps:

1. Add a repository on Redmine with the original repo of gitolite's repository. The path would be something like /home/git/repositories/my-repo.git.

2. Initially, Redmine doesn't have any permissions to read the repository, so we fix the problem by adding the Redmine user (usually www-data or apache) to the git group by running usermod -a -G git www-data (be aware of your server's configuration, because that can be a little different, according to how you configurated gitolite.

3. Change the UMASK property on the .gitolite.rc file, from the default value of 0077 to 0022, the equivalent of 755 (rwxr-xr-x) for directories and 644 (rw-r--r--) for files.

4. For existing repos, you might need to run a chmod -R g+rX

If you still experience the permissions trouble with Redmine, where it opens a 404instead of the repo on the repository tab, you might have to run a chmod -R g+rX on the whole /home/git/repositories, in order to make sure the Redmine user can read all the way through the repos.

gitolite post receive hook for specific bare repo

Update August 2013, with the latest gitolite:
You now have official specific repo hook:

it's basically just creating a symlink in <repo.git>/hooks pointing to some file inside $rc{LOCAL_CODE}/hooks/repo-specific (except the gitolite-admin repo)

---

Original answer (

First, if you are using gitolite V3, you can define any hook, including a post-receive hook (except the update hook, see using hooks) : previously, with gitolite V2, pre-receive hook was reserved.

Now you can add a hook by copying it in the gitolite-admin/common/hooks local clone directory, and pushing gitolite-admin back to the gitolite server: gitolite will make sure that hook is declared for all bare repos it manages.

You can also add directly your hook on the server at a separate location designed by the $LOCAL_CODE "rc" variable ("rc" means defined in your gitolite.rc config file): $LOCAL_CODE/hooks/common. See "customizing gitolite".

The idea is to make sure a gitolite upgrade doesn't erase any of your custom programs.

Simply define a 'post-receive' file, executable (chmod 755), and copy it in the common/hooks directory of your choice (gitolite-admin local repo plus git push, or .gitolite on the server, or $LOCAL_CODE on the server).

Note: that fact that you don't see a 'post-receive.sample' file doesn't prevent you to define that hook.

If done directly on the server, you need then to run gitolite setup --hooks-only in order for your custom hooks to be setup on all bare repos.

What you would never do is to copy it directly on one of your bare-repo.git/hooks directory: that is the job of gitolite to publish "common" hooks to all your bare repo.

That way, you can manage them directly through any clone of gitolite-admin repo (pushing back that repo will update any hook that you might have changed).

"All bare repo" means your post-receive hook must know what bare repo it operates on:

You can do that by checking the value of $GIT_DIR (set to the root .git directory of the bare repo on which this hook is running).

Finally, for this kind of post-receive hook, see "Git checkout in post-receive hook: “Not a git repository '.'”":

You need to define GIT_DIR and GIT_WORK_TREE explicitly to the destination repo in order for your git pull to succeed.

 GIT_WORK_TREE=/Users/me/Sites GIT_DIR=/Users/me/Sites/.git git pull

---

Related Topics