Add a special variable `%GL_CREATOR` to the the git-config trigger that
is replaced by the name of the repository creator (if any).
This can be useful to set up the default owner configuration for wild
repositories.
Example:
repo assignments/CREATOR/a[0-9][0-9]
C = @students
RW+ = CREATOR
config gitweb.owner = %GL_CREATOR
----
committer added an if condition to the s/// line.
Background
* I needed to have the documentation under CC-BY-NC-SA (something
happened to force me to choose)
* Distros don't like the NC part. They'd rather drop the
documentation entirely instead
* I don't like that; it bothers me that even a clueful guy won't be
able to do a basic install with what comes in the package.
* Meanwhile, I have always had the occasional "TL;DR" complaint about
my docs
Taking all this into account, it seemed like the best way was:
* Create a brand new README.txt that is crisp enough for someone to
glance through and quickly get started. At more then 300 lines, it
covers enough ground that probably 60% of sites don't need more.
Put this under the CC-BY-SA license, which is on the "good" list for
Fedora (and also Debian, I am told).
* Move the current documents to a new "gitolite-doc" repo that distros
can simply ignore, but anyone who has trouble can go to.
Make sure the online pages have the same content at the same URLs as
they do now, getting it instead from this new repo.
Link to the main URL in the new README.txt
- non-core documentation reduced to be easier to maintain
- much reduced progit section submitted to scott chacon, necessitating
some changes to this copy
- other minor stuff
- the "idiot-proof setup" :)
(plus get rid of that silly "dot.pl"; it's not needed any more, if it
ever was!)
Only '+' sign was unescaped in `http_simulate_ssh_connection()`.
When user translates `ssh git@host perms <repo> + <role> <user>` to
`curl https://host/git/perms?<repo>+%2b+<role>+<user>` nothing happens.
This commit fixes it modifying url unescaping.
committer notes: changed the regex per 'man URI::Escape'
(manually tested)
- new rc var: GL_BINDIR2; see doc update in this commit
- added _which() function to search both $GL_BINDIR and $GL_BINDIR2
- 'gitolite <command>', non-perl triggers, VREFs, and sugar, use this
- unshifted $GL_BINDIR2/lib into @INC upfront in Rc.pm
- perl triggers use this
- git version bumps up, causes minor change in t/merge-check.t
- for some strange reason apache cannot see /tmp/gitolite-http-authuserfile
(I thought private /tmp was only if you enabled selinux...)
i.e., a client fetch will invoke the push, (subject to 'nice' setting),
but you can also force a fetch regardless of last fetch time by running
this command directly on the server:
gitolite ../triggers/upstream fetch <reponame>
Also, use FETCH_HEAD instead of own sentinel file (idea courtesy Luke Lu)
'gitolite query-rc' now only queries one variable at a time. That is,
you cannot do something like this:
gitolite query-rc UMASK GL_ADMIN_BASE
to query both variables. I think this is rarely used, plus it is easy
to work-around (just run two separate commands), so it was sacrificed
for the ability to do this:
gitolite query-rc -q COMMANDS fork
which tells you whether $rc{COMMANDS}{fork} exists or not.
If a user has multiple keys, ssh-authkeys-shell-users will only add the
"-s" flag to the first key it finds. Change the substitution to apply
to all matching lines and hence grant shell access to all of the user's
keys.
Signed-off-by: John Keeping <john@keeping.me.uk>
- fix docs to explicitly state that mirroring wild repos is a bad idea
if the authentication data is not the same on the peers.
- an important check against a malicious peer was missed out. If
people heed the warning above this check is not really needed but it
is good for completeness.
- warning about redirected pushes removed, thanks to Ronald Ip having
tested it and reported it working.
It creates the repo on the remote side (getting the creator name from
the gl-creator file and sending it across), as well as sending gl-perms
on subsequent connections.
This has only been minimally tested. E.g., complex setups or asymmetric
configs on master and slave, etc. have NOT been tested.
This has also not been tested with redirected pushes.
repo foo
desc = "foo"
RW = u1
...etc...
The order of the clauses was parsing this like the old 'reponame = "some
description"' and end up creating a repo called 'desc'!
It would also, as a side-effect, change the repo so what you thought
were access rules for 'foo' would become access rules for 'desc'.
