what does gitolite setup fix?

Question

gitolite info didn't work, adding keys turned them into a no access key and did NOT create a corresponding entry in auth-keys file.

To fix this run gitolite setup on gitolite server

Question: what could have landed me in that mess?

And what does gitolite setup do when invoked for the n-th time (it's no longer setting things up, according to the docs it fixes hooks, but I wonder what the use case would be and which was mine)?

More details on gitolite info

gitolite info command is invoked like so:

> ssh git-user@ser-git
PTY allocation request failed on channel 0
hello git-admin, this is ...@... running gitolite3 3.6.7-2 (Debian) on git 2.17.1

 R W    some-repository
 R W    gitolite-admin
 R W    testing
Connection to ser-git closed.

Bad output is: FATAL: unknown git/gitolite command: 'info'

More details: keys without access.

gitolite sshkeys-lint was showing keys with (no access), now those keys have access as I set them (now meaning after gitolite setup).

ssh-keygen -lf /home/repo/.ssh/authorized_keys | wc -l (or without piped part, regardless) number of keys and their names indicated I didn't have the newest one added.

Similar question that did not work for me: keydir entries not propagating to authorized_keys

Answer 1

Docs pretty much had the answer once I dug deeper, I guess. Which is fairly nice of @sitaramc.

• Without options, 'gitolite setup' is a general "fix up everything" command (for example, if you brought in repos from outside, or someone messed around with the hooks, or you made an rc file change that affects access rules, etc.)

Symptoms keys stopped propagating and error FATAL: unknown git/gitolite command: 'info' on ssh git-user@ser-git. Fix was to run gitolite setup. So onto first question, the title one:

what does gitolite setup fix?

1. gitolite setup is implemented here

2. my Perl is rather weak, but there's a setup function in line 56. It calls args (which parses options, so here it had nothing to parse), then unless h_only (hooks only arg for setup), which wasn't used, so we skip compile and POST_COMPILE trigger and go for the hooks.

   sub setup { my ( $admin, $pubkey, $h_only, $message ) = args();

   unless ($h_only) {
       setup_glrc();
       setup_gladmin( $admin, $pubkey, $message );
   
       _system("gitolite compile");
       _system("gitolite trigger POST_COMPILE");
   }
   
   hook_repos();    # all of them, just to be sure
   

   }

3. package Gitolite::conf::store has hook_repos(), line 228: we change the dir to repo base dir (as per config file), and for each phy_repo we do hook_1(phy_repo). What is a phy_repo? a physical one.

4. same package, different method and line: hook_1($repo) in line 354.

Method hook_1($repo)

It's quite literally about fixing all the hooks.

1. Recreates dirs for common and admin hooks.
2. Rewrites update_hook (common) and post_update_hook (admin).
3. Sets 755 permissions for both common and admin hooks.
4. Then using ln_sf it symlinks the folders for common/admin hooks.
5. ln_sf is in common module, in line 162