Gitolite Remote Commands
A number of useful commands can be triggered by both admins and devs, by ssh-ing to firstname.lastname@example.org. These are gitolite's admin defined commands. The following alias is also useful (and used in the examples below):
info command to see which repositories you are allowed to access. Use the
expand command to show the full list of repositories to which this expands:
Note that the patterns shown in the output are regular expressions, not shell globs (i.e., '.' character is a stand-in for 'any character', and not a dot as it is with shell globs).
Creating a Repository
Repositories are actually auto-created when you try to
push, or perform any other operation on a nonexistent repository. For example:
Creating a repository in the
LSST hiearchy requires a special procedure.
Deleting a Repository
To remove a repository (assuming you are its owner), use the
This command doesn't actually delete the repository; it only moves it to
list-trash to see what's in the trash, and
restore, to restore a deleted repository from the trash. To permanently delete a repository, someone with the git account password must do the following:
This is a safety feature: it should be very hard to permanently delete anything from a repository.
Forking a Repository
Forking is essentially making a server-side repository copy (a clone), allowing you to clone an existing repository (e.g., for experimentation). For example:
This now gives me a full clone of afw, with full rights to all of its tags/branches/etc. Note: the server-side clone is done in a very space-efficient way (hardlinking is used where possible). If you want to fork the repository to a remote site (e.g., for control of the stability of the stack while retaining the ability to exchange commits), see this.
Renaming or Moving a Repository
To re-name or move a repository, do:
Unlike UNIX mv,
<to_name> cannot be a directory: it must be a fully-qualified repository name. For example:
Note that the
.git extension is optional in the above command.
Creating a Repository in LSST/ Hierarchy
One cannot directly create (or delete, but you can trash) repositories in
LSST/, but if you're a member of @admins, you can move an existing user repository there using:
Since repositories are auto-created if they don't exist (see above), allowing even a small subset of @admins to create them in the
LSST/ hierarchy may lead to lots of spurious repos due to typos. Because of that, only the user '
root' is allowed to create (or delete) repositories in
LSST/, and user '
root' can only be accessed using the '
sudo' command. This adds an additional layer of safety.
Deleting a Repository (that you don't own)
To remove a repository (if you are not the owner), check who is the owner, and run the
trash command as the owner:
SSH-ing into the git Account
Use a password to get shell access (as keys will redirect to gitolite). To force SSH to skip public key auth, do:
Managing LSST gitolite Users and Permissions
User and permission management is done via configuration files in the standard gitolite-admin repository. You have to be a member of @admins gitolite group to access this repository. Membership consists of roughly one person per DM site. For the exact list, contact lsst-admin@...
For user management activities, first clone gitolite-admin to your local machine:
Adding or removing users
Add the user's SSH public key to a file named email@example.com in the gitolite-admin repository. For example, to add user mjuric, add mjuric's public key into:
If the user has more than one key, add as many as necessary by changing the numeric suffix following the @ sign (e.g., firstname.lastname@example.org, etc.).
Next, add the user to conf/devs.conf, to the @devs group. For example:
@devs = mjuric
Commit the changes, and push them upstream to make the changes effective:
To remove users, simply remove the public keys and their entries from
conf/devs.conf file, then
Removing Accident From a Repository
Large files (usually, test data) have on occasion been added accidentally to a repository. Below is a recipe for
@admins to remove them.
NOTE: This is history rewriting and should be done only after consulting mjuric!
git clone, plus don't forget to create another clone for safety, comparison, etc.
In our case the
<pathToFile> looked like
tests/case02/data/Source.txt etc. Repeat for every file you are removing.
Remove the files push the result (using the force):
- Checkout the branch where the offending files were committed and "
git push --force"that branch
To back up all of the repositories simply back up anything and everything in
~git. Note that
~git/repositories is a symlink to
/lsst_ibrix/gitolite/repositories, that should be backed up as well.