From: Sitaram Chamarty <sitaramc@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: [Announce] gitolite 1.0
Date: Tue, 9 Feb 2010 18:45:26 +0530 [thread overview]
Message-ID: <2e24e5b91002090515o356c53baib1f5f750e0d67dba@mail.gmail.com> (raw)
Gitolite is an ssh-based access control tool for using git in a typical
"corporate" environment. The original goals were very simple:
read/write/rewind access control at the git branch level, the ability to
install on any Unix, no need for root access, and no need for additional
software (other than git and perl).
There is plenty of documentation included with the source, because by
now it has acquired a lot of features not originally planned.
I now consider gitolite to be at 1.0, and this note summarises the
features added since the last email to the list [1] about gitolite.
Please see README.mkd and doc/3-faq-tips-etc.mkd for *all* the details
if you are completely new to gitolite.
* Install/upgrade can now be done even from the bash that comes with
msysgit. This means pretty much anyone can quickly and easily
install gitolite on any Unix server.
* You can specify an "owner" and a "description" for gitweb to
display. The syntax is very simple, here's an example:
gitolite "Sitaram Chamarty" = "fast, secure, access control for git"
* You can include any site-specific (custom) hooks that you want to
propagate to any repo created by gitolite.
* The "deny access" feature can be very useful sometimes; an example
that shows how only bob may push version tags would look like this:
@devs = alice bob charlie
RW refs/tags/v[0-9] = bob
- refs/tags/v[0-9] = @devs
RW refs/tags/ = @devs
More details can be found in the documentation.
* Gitolite can now let you specify restrictions based on file/dir
names (for example, restrict who can push changes that touch some
file or directory).
My initial response to this request was that this is better done by
the social mechanisms of the project team, and I do not believe this
feature is really necessary in a well-run project.
However, people coming from other VCSs seem to make this a sticking
point at work, so I added it anyway, if only to see how far I could
stretch gitolite's config file while keeping its simplicity intact
:-)
----
I'm often on #git, subject to my living in UTC+0530 time, and email is
also welcome (sitaramc <at> gmail.com is preferred, but sitaram.chamarty
<at> tcs.com may get my attention quicker). Feel free to contact me
with questions or feedback.
--
Sitaram
[1]: http://article.gmane.org/gmane.comp.version-control.git/131834
--
Sitaram
reply other threads:[~2010-02-09 13:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e24e5b91002090515o356c53baib1f5f750e0d67dba@mail.gmail.com \
--to=sitaramc@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).