the optimisation that I just broke here was responsible for a bug that
ignores config entries if you also had a description there
repo @all
config foo.bar.testAAA = "testAAA"
repo foo1 foo2
RW+ = u1 u2
R = gitweb
foo1 "sitaram" = "some project"
This is because the %git_configs hash has been wiped out earlier (when
can_read($repo, "gitweb") was first called) yet now you're not giving it
a chance to get filled because $desc short-circuits can_read.
(incidentally, this is one of those things that makes g3 so nice in
comparision, because I decided not to be so fixated on efficiency!)
- git prepends a '/' when people use the full form of an ssh URL.
Since I *never* use those, (I prefer setting an ssh host alias and
just saying 'git95:gitolite' for example), I never caught this.
- people will also append a '.git'. It's supposed to work either way,
but it wasn't. I had missed a few places where the user might send
in 'reponame.git' and was implicitly assuming it would be 'reponame'
- finally, we slip-streamed in a wrapper for system()
Big thanks and kudos to Michael Brown for catching these issues, and
(hopefully, heh!) testing my fixes ;-)
When someone adds a repo-specific hook to their repo, then create a
'fork' via the fork ADC, this repo-specific hook also get carried
across, but should not.
- 'dupkeys' -- catch duplicate keys in keydir
- 'email-check' -- "you can only push your own commits"
plus, 'merge-check' -- how we could have done the no-merges policy
- compile: VREF/ is special, like NAME/
- update hook: use a new "check_vrefs" sub to
- spawn helpers for each vref in @allowed_refs
- for each vref returned by the helper, call check_ref
OK I agree the starting line was *just* misleading enough to give the
opposite impression, but still, when the next para starts with "The
rules are..." wouldn't you expect people would read *that* too?
- redo it in perl
- make it flow easier, with all the cruft in subs
and overall, make it obvious that this program does for a manual install
what doc/packaging.mkd advices packagers to do.
- move wrap_mkdir() to gitolite.pm
- remove junk left over from days when dinosaurs ruled the world
- reuse setup_environment() from gitolite.pm instead of rolling our
own code for PATH and umask
part of it's function (the rest is harmless)
- and most important, remove the last vestiges of the old 'from
client' install method, in the form of 'if ($GL_PACKAGE_HOOKS)'
lines
- clean up the symlinking to be more precisely in line with
doc/hook-propagation.mkd (especially, remove the 'quirk' that
package hooks would also get copied to the user hooks area)
The instructions were written before gl-admin-push was created, I guess,
making things sound a lot more complicated than they should be.
Thanks to Nick (see gitolite mailing list messages, subject line
"replicating a gitolite installation") for helping me realise this
needed fixing.
This compensates for an selinux bug reported on #gitolite by John Hawley
(warthog9). sh/bash uses a tempfile to do this, which in turn causes
some problems in selinux; I really don't [need to] know more than that.
*Technically* this is a bug in selinux/policy, and would qualify for an
entry in "nagp"... but:
(1) the changes are small and localised
(2) the problem makes gitolite -- currently -- unusable with selinux,
and what use is a security program which can't run under selinux
(regardless of whose fault it is)?
and finally
(3) if I can't break my own rules for one of my most high-profile users
then what's the point of owning the code?
:-)
----
Implementation notes: I've only done this for code that is likely/meant
to be used in production
I also slip-streamed in a URL fix (from when I changed all the online
document rendering)
Please don't use this setting in a production system but in some
environments it is needed for completely automated *testing* to be able
to use ssh correctly.
Thanks to Kacper Kornet for catching this...
(by the way, there's a simple workaround if you are affected by this but
can't upgrade to this commit or later: just create an empty
$PROJECTS_LIST file, which is by default ~/projects.list)
If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will
get caught later when someone whom youhave given that role tries to
access the repo (look for another occurrence of the same error message
as this one).
So there's no access violation but it would be nice to be told upfront
that it won't work.
