Having to specify "D" separately from RW or RW+ was cumbersome, and
although I don't actually use this feature, I can see the point.
One way to think of this is:
- RW and RW+ were the only existing branch level rights
- it doesnt make sense to have D rights without W (hence RW) rights
- so we simply suffix a D to these if required.
Thus you can have RW, RW+, RWD, RW+D.
I hope the (hopefully few) of you who have started to use this feature
will convert your configs when you next upgrade to "pu".
I now regret pushing the previous syntax to master too quickly -- lots
of people use master only, and on the next promotion of pu the syntax
will change. To reduce this exposure, this change will be promoted to
master very soon.
Previous implementations of "give shell access to some gitolite users"
feature were crap. There was no easy/elegant way to ensure that someone
who had repo admin access would not manage to get himself shell access.
Giving someone shell access requires that you should have shell access
in the first place, so the simplest way is to enable it from the server
side only.
So now that we decided to do that, we may as well prepare for other,
future, commands by starting a server-side utility program with
sub-commands (the only current one being "shell-add")
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.
There are some disadvantages to the old-style personal branch scheme.
It only allows one specific pattern (of refname) to be used, forces that
pattern to be applicable to *all* repos in the entire config, and
requires editing the rc file (on the server) to be edited to achieve
this.
In other words, it's a very blunt instrument...
The new style depends on using lines like this within a specific repo
config:
RW+ personal/USER/ = @userlist
The important thing is that the "branch" name should contain `/USER/`
(including the slashes). Access is still determined by the right hand
side of course.
This gives you the following advantages:
- allow it only for repos that need it
- allow different patterns to be used for different repos
- allow *multiple* patterns; just add more than one such line
- allow the pattern to have suffixes (eg: foo/USER/bar)
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
(about this commit)
The install doc now describes both the ways of installing gitolite.
It also has a handy appendix for package maintainers describing what
they need to do.
(about the "dps" -- distro packaging support -- commit series)
This commit is the last in the chain meant to make gitolite more
friendly for package maintainers.
Frankly, I never really thought gitolite would get big enough or
important enough for someone to package it, and I always did just
the bare minimum I needed to get it working, first for myself, then
anyone who hopped onto #git and asked. As a result, it had some
quirks in terms of what is expected where and so on...
Luckily, it didn't take a lot of changes to fix it, and this series
of commits should help make it very easy to package gitolite for
system-wide use.
The wildrepos branch has been merged into master, and deleted. It will no
longer exist as a separate branch. Instead, a new variable
called $GL_WILDREPOS has been added which acts as a switch; when
off (which is the default), many wildrepos features are disabled.
(the "C" permissions, and the getperms (etc.) commands mainly).
Important: if you are using wildrepos, please set "$GL_WILDREPOS = 1;" in
the RC file when you upgrade to this version (or just before you do the
upgrade).
lots of conflicts, esp in gl-auth-command, due to refactoring the
"special commands" stuff on master
Conflicts:
doc/3-faq-tips-etc.mkd
src/gitolite.pm
src/gl-auth-command
src/gl-compile-conf
great idea by Robin Smidsrød: since users are already capable of
authenticating themselves to gitolite via ssh keys, use that to let them
set or change their own HTTP passwords (ie, run the "htpasswd" command
with the correct parameters on behalf of the "git" user on the server)
code, rc para, and documentation. In fact everything except... ahem...
testing ;-)
and while we're about it, we also reorganised the way these helper
commands (including the venerable "info" are called)
This is actually a pretty big deal, and I am seriously starting wonder
if calling this "gito*lite*" is justified anymore.
Anyway, in for a penny, in for a pound...
This patch implements a generic way to allow access control for external
commands, as long as they are invoked via ssh and present a server-side
command that contains enough information to make an access control
decision.
The first (and only, so far) such command implemented is rsync.
Please read the changes in this commit (at least the ones in conf/ and
doc/) carefully.
It's not clear whether $projectroot has or does not have a trailing
slash. Current code assumes it does, but we need to cater for it not
having one also. Otherwise the final reponame ends up with a leading
slash, once $projectroot has been stripped from the beginning of the
full repo path.
I know hardly anyone is using delegation, but if you find yourself
locked out from pushing because of this one little thing, do this:
* on your gitolite-admin clone, add the required lines per this patch,
and commit
* on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and
delete the following line
'NAME_LIMITS' => 1
from the entry for "gitolite-admin" (if you don't know what that
means delete *all* such lines) and save the file
* back on your admin repo clone, do a push
I know hardly anyone is using delegation, but if you find yourself
locked out from pushing because of this one little thing, do this:
* on your gitolite-admin clone, add the required lines per this patch,
and commit
* on the server, edit ~/.gitolite/conf/gitolite.conf-compiled.pm, and
delete the following line
'NAME_LIMITS' => 1
from the entry for "gitolite-admin" (if you don't know what that
means delete *all* such lines) and save the file
* back on your admin repo clone, do a push
Stop conflating the privilege to push changes to the admin repo with the
privilege to get a shell on the server.
Please read doc/6 carefully before upgrading to this version. Also
please ensure that the gitolite key is *not* your only means to get a
command line on the server
This is a backward incompatible change. If you are using delegation and
you upgrade to this version, please do the following:
* change your gitolite.conf file to use the new syntax (see
doc/5-delegation.mkd in this commit)
* for each branch "foo" in the gitolite-admin repo, do this:
# (on "master" branch)
git checkout foo -- conf/fragments/foo.conf
* git add all those new fragments and commit to master
* delete all the branches on your clone and the server
# again, for each branch foo
git branch -D foo
git push origin :foo
