If you have many thousands of repos and users, neatly organised into
groups, etc., the normal gitolite fails. (It actually runs out of
memory very fast while doing the "compile" when you push the config, due
to the number of combinations of repo/user being stored in the hash!)
This commit series will stop doing that if you set $GL_BIG_CONFIG = 1 in
the rc file.
Some notes:
- deny rules will still work but somewhat differently -- now they must
be placed all together in one place to work like before. Ask me for
details if you need to know before I get done with the docs
- I've tested most of the important features, but not every single
nuance
- the update hook may be a tad less efficient now; we can try and
tweak it later if needed but it shouldn't really hurt anything
significantly even now
- docs have not been written yet
Ouch! How mortifying :) I'd always thought this was one of the Brit/US
differences, but to find out that it really *isn't* a word... hmph!
Anyway, in the interest of not breaking existing wild repos, the
ownership file is still called "gl-creater". Everything else has been
changed.
(...thanks to Sverre)
SECURITY NOTE: if you deleted or renamed a pubkey file after 5fd9328
went in (April 12th), please:
- upgrade asap, then
- go to your latest gitolite-admin clone and "git push -f"
Otherwise this is not urgent.
5fd9328 (and its minor successor 813a2a9) were about preventing the
gitolite admin from sneaking in files to src/ and hooks/ into
$GL_ADMINDIR. It seemed easy enough to do this by converting the
path-less checkout to a with-paths checkout, but this has caused a worse
problem -- deleting a keydir/foo.pub now no longer has an effect; the
file still hangs around in the work tree.
Ouch! (and thanks to teukka for noticing)
We now do this check as a separate step, so the checkout can revert to
being path-less.
This is a pretty big hole, really. Only the fact that Eli called it an
"accidental feature" helped catch it :)
Notes on the code:
An explicit list of paths -- maybe just "conf", "keydir", and "local" --
would have been easier, but this isn't too bad, I think.
people with shell access should be allowed to bypass the update hook, to
allow them to clone locally and push. You can now do this by setting an
env var that the ssh "front door" will never set, like so:
GL_BYPASS_UPDATE_HOOK=1 git push
Note that this will NOT work for the gitolite-admin repo, because the
post-update hook on that one requires a bit more. If you really want to
do that, try:
GL_ADMINDIR=~/.gitolite GL_BINDIR=~/.gitolite/src GL_BYPASS_UPDATE_HOOK=1 git push
(assuming default values in ~/.gitolite.rc)
normally, RW+ means permission to rewind or delete.
Now, if you use "D" permission anywhere in a repo config, that means
"delete" and RW+ then means only "rewind", no delete.
- no need to put it at the end of the config file now, yeaaay!
- @all for @all is meaningless and not supported. People asking will
be told to get a life or use git-daemon.
- NAME/ limits for @all repos is ignored for efficiency reasons.
The new style personal branches work by interpreting the special
sequence /USER/ (including the slashes) in a refname. Docs should be in
the next commit...
the changes to cp/scp are because without "-p" they dont carry perms
across to existing files. So if you forgot to chmod +x your custom
hook and ran easy install, then after that you have to go to the server
side to fix the perms...
when repos are copied over from elsewhere, one had to run easy install
once again to make the new (OS-copied) repo contain the proper update
hook.
We eliminate this step now, using a new, empty, "hook" as a sentinel and
having "compile" check/fix all repos' hooks.
Since you have to add the repos to conf anyway, this makes it as
seamless as possible. The correct sequence now is
- (server) copy the repo at the OS level
- (admin clone) add it to conf/gitolite.conf, commit, push
