[gitolite] symlink hooks instead of copying them

Dear Sitaram, dear Teemo, dear gitolite-fans,

Gitolite currently copies hooks to repositories. For upgrades, it must thus ensure that all hooks are also upgraded.

It occurs to me that this might be easier done using symlinks, or with a file that includes the master hook(s) in ~/.gitolite/src/hooks. Then, the hooks just have to be upgraded in one place.

Do you see a reason not to do this via symlinks?

On Thu, Feb 04, 2010 at 09:47:23AM +1300, martin f krafft wrote:

If you mean just the gitolite-specific hooks (the update hook for all repos, and the post-update hook for the admin repo) then no problem.

The other hooks I'd rather not assume anything about. The current scheme forces an overwrite of the gitolite-specific hooks, as well as any hooks given in src/hooks, each time an "install" is done. It does not touch any *other* hooks, which allows the admin to (via command line) place specific hooks in specific repos manually if he wishes to.

I'm ok with symlinking stuff; a couple of "cp" commands would change to "ln" :) Let me try it out (and make sure it works for upgrades also...)

On Thu, Feb 04, 2010 at 09:47:23AM +1300, martin f krafft wrote:

I forgot... part of the reason this "copy all hooks over each time you run install" is also to give people an easy way to update the hooks when the repo was *copied* from elsewhere, and not *created* by gitolite in the first place.

Basically I'm paranoid about that "update" hook, without which the branch level access control doesn't work at all.

So this will still need to be done. Or you'll have to provide some other command that will sweep through all repos in the $REPO_BASE and check that the symlink is pointing to the right place etc etc.

Any other ways of doing this? I'd rather keep it as is, if it's OK with you, except for changing the cp to ln of course.

also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:

ln -sf even.

also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1435 +1300]:

Wouldn't it thus make sense to check during authentication that the symlink exists and points to the right file, and to deny access completely if that isn't the case?

Having a mass-update command for this might be nice, but I suppose it's also a trivial shell one-liner...

  for i (**/*.git/hooks/update) \
    ln -sf ~git/.gitolite/src/hooks/update $i

(this is zsh, not sure bash can do this yet)

On Thu, Feb 04, 2010 at 02:46:57PM +1300, martin f krafft wrote:

yup...

Yeah I guess that's easy enough really... just need to include a way to tell the code what is the right file to point to. (Currently it's all inside $GL_ADMINDIR but in the APT case that may not be true...?)

This has to work on systems that don't even have bash (like plain old sh personality of ksh), leave alone zsh :)

Not saying it's hard; just a "find" in backticks. I'd still rather put it inside the perl code somewhere that already gets run anyway, as it is now...

also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1622 +1300]:

How about comparing the hash sums of where you think the file is? This would also ensure that repo access was disallowed if the hook hasn't been upgraded without symlinks (though I think the symlinks are still better than copies, and more expressive too). Does that fit your level of security-paranoia? ;)

About the APT case — leave that to us. If we distribute gitolite from /usr/share/gitolite, then we'll probably be patching the entire source anyway. Obviously, if it proves viable, then it might make sense to bring back that functionality and have it configurable at install or runtime.

No objection.

Thanks!

On Thursday, February 4, 2010 at 14:46:57 (+1300) martin f krafft writes:

Does 'ln -sf' work reliably on all distros? I seem to recall on Ubuntu 7.10 that this was broken.

Bill

also sprach Bill Lear <rael@zopyra.com> [2010.02.04.1917 +1300]:

unlink && symlink in Perl is probably preferably anyway.