otherwise repo names containing "@" in them were causing the @foo part
to be interpolated (as empty of course) instead of being taken literally
reported by silvio dot fricke at googlemail
(and in one other place it needs to be defined earlier)
I never caught this because in my testing those error conditions --
caused by lack of afc3a06 -- never came up.
I'd originally written some minimal documentation for this ADC, but I
liked Jeff's version so much that I borrowed it, added the final section
("important notes for the admin"), made a few other minor fixups, and
then happily ditched my version.
(the ones that require GL_BYPASS_UPDATE_HOOK to be set are done slightly
differently because I just didn't want all the hassle of saving and
restoring that variable on the perl side)
The need for this comes about as follows:
- a project may allow its developers "RWC" (or "RW+C") so that they
can create feature branches when needed. Note that these are
*feature* branches, so they can't use the "personal branches"
mechanism that gitolite already has.
- the developers are *not* given RWCD (or RW+CD) to prevent accidental
deletion of an important branch. Branch *deletion* is something
that only a few trusted admins can do.
- as a result, there are sometimes situations where a developer
creates a misnamed branch and then has to ask the admins to help get
rid of it.
What the KDE folks wanted was a way to allow the creator of a branch to
be able to delete it. In addition, they needed this allowed only for a
fixed duration after the creation of a branch, not forever (for the same
reason they don't get RWCD, to prevent accidents).
These are my reasons why this feature is implemented as an ADC instead
of being "in core":
- we'd need additional syntax to differentiate this special case
(which is sort of in between RWC and RWCD, if you think about it).
I'm reluctant to complicate the syntax further for something that is
only occasionally needed.
- we'd need either (a) code to parse the log files, or, (b) code to
maintain "who created this ref" on every push that creates a ref.
- parsing the log files is too kludgy and inelegant to be in core,
not to mention potentially very slow for really large projects
- code to maintain the a history of "who created this ref" is too
cumbersome, especially because of the need to expire old entries
after a time.
This new adc allows you to run arbitrary git commands on the server.
It is disabled by default, and you have to READ ALL INSTRUCTIONS **AND**
SOURCE CODE BEFORE DEPLOYING.
For sample code see new file contrib/adc/get-rights-and-owner.in-perl.
Despite the name, you can use similar code in a hook also -- comments in
that file will tell you how.
implementation notes:
- check_access now takes an optional last arg "dry_run", which is also
passes through to check_ref
- check_ref returns a "DENIED by ..." instead of die-ing if dry_run is
passed in
- as a side effect, cli_repo_rights is now just a stub calling
check_access (we kept it hanging around for backward compat -- too
much adc pain for too many people if we change it now)
(we quietly do not document the 'able' adc, which is now the most
"official" adc in the sense that it has a new test, t64-write-able!)
other notes: fix bug in 'able' (not setting $loc)
- get_rights_and_owner normalises its arg1 by stripping .git if
supplied, then sets the variable "repo" to the result as a side
effect
- new "help" adc with some default text but main purpose is to allow
site local help text
- other adc's refer to 'help' adc when appropriate
- 'undelete' renamed to 'restore'; that's what the KDE "trashcan"
program calls that operation
- minor typo in sample script in documentation
- main adc doc points to contrib/adc/repo-deletion.README now
The sudo adc should make life easier for any admin wishing to run an adc
as some other user.
As a result, the rmrepo adc also goes back to its simple roots. Now you
just run it via the sudo adc if you (as gitolite admin) needs to rmrepo
some user's repo.
- dont do anything if he doesn't even have read access
- move the GL_USER check to the right place! (to when you actually
will be doing something)
That spurious check for GL_USER that we (re)moved would not only have
shown an incomplete set of log lines, it would have made the wrong log
line look like the "last" one. (No real harm would result, of course,
since the update-ref would blow up due to the actual SHA being something
other than what it was expecting, but it would be confusing to the user)
