2.7 KiB
brief descriptions of the shipped ADCs (admin-defined commands)
(...with pointers to further information where needed)
able: enable/disable push access temporarily (such as for taking backups or other admin chores); details here.
delete-branch: allow someone to delete a branch that they themselves created. (i.e., when the user had RWC, but not RWCD, permissions). Details on this ADC are here; details on RWC/RWD/RWCD etc are here.
fork: Think of it as a server-side clone; details here.
get-rights-and-owner.in-perl: Most of the ADCs are in shell, so this is a sample of how to write an ADC in perl.
gl-reflog: show a fake "reflog" from the server, and allow recovery from deleted branches and bad force pushes; details in source.
help: not all shipped ADCs may be enabled by the site admin. Conversely the admin may create and install his own ADCs that dont ship with gitolite itself. This ADC displays site-local help, if the site admin enabled it.
hub: allow "pull requests" a la github; details here.
rm, lock, and unlock:
trash, list-trash, and restore:
two families of repo deletion commands; details here
restrict-admin: sample program to show how you can allow the admin to run pre-specified shell commands (without actually having full shell access). Details here.
sudo: allow admin to run ADCs on behalf of a user. Useful in support situations I guess. Details in source.
Note: the Unix "sudo" and "su" programs are most often used to acquire higher privileges, although they're actually designed to go the other way also. In gitolite we do not do the former, only the latter (i.e., a normal gitolite user cannot do admin-stuff using this ADC).
su-expand, su-getperms, su-setperms: as above, but for the internal commands 'expand', 'getperms', and 'setperms'. (These commands are not ADCs so you cannot simply use the 'sudo' ADC described above).
who-pushed: find the last person to push a given commit; details in source.