deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

(minor) doc tweaks

Browse source
This commit is contained in:
Sitaram Chamarty 2011-05-16 18:51:43 +05:30
parent 936f8719ce
commit 31cd56b76d
5 changed files with 19 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
README.mkd
View file

@ -94,8 +94,9 @@ But there are several disadvantages here:
impossible without extraneous tools impossible without extraneous tools
* errors or omissions in setting the permissions exactly can cause problems * errors or omissions in setting the permissions exactly can cause problems
of either kind: false accepts or false rejects of either kind: false accepts or false rejects
* without going into ACLs it is not possible to give someone read-only * without going into ACLs it is not possible to give some people read-only
access to a repo; they either get read-write access or no access access while some others have read-write access to a repo (unless you make
it world-readable). Group access just doesn't have enough granularity
* it is absolutely impossible to restrict pushing by branch name or tag * it is absolutely impossible to restrict pushing by branch name or tag
name. name.

11
doc/2-admin.mkd
View file

@ -62,10 +62,11 @@ Once you've cloned it, you're ready to add users and repos.
if you wish, since the entire tree is searched. if you wish, since the entire tree is searched.
* edit the config file (`conf/gitolite.conf` in your admin repo clone). See * edit the config file (`conf/gitolite.conf` in your admin repo clone). See
`doc/gitolite.conf.mkd` in the gitolite source for details on what goes in [doc/gitolite.conf.mkd][confmkd] in the gitolite source for details on
that file, syntax, etc. Just add new repos as needed, and add new users what goes in that file, syntax, etc. Just add new repos as needed, and
and give them permissions as required. The users names should be exactly add new users and give them permissions as required. The users names
the same as their keyfile names, but without the `.pub` extension should be exactly the same as their keyfile names, but without the `.pub`
extension
* when done, commit your changes and push. Any new repos you specified will * when done, commit your changes and push. Any new repos you specified will
automatically be created (empty, but clonable) and users' access will be automatically be created (empty, but clonable) and users' access will be
@ -380,4 +381,4 @@ It does not (currently) support other options like `--add`, the `value_regex`,
etc. etc.
[genpub]: http://sitaramc.github.com/0-installing/2-access-gitolite.html#generating_a_public_key [genpub]: http://sitaramc.github.com/0-installing/2-access-gitolite.html#generating_a_public_key
[confmkd]: http://sitaramc.github.com/gitolite/doc/gitolite.conf.html

2
doc/gitolite-gitweb-http-backend.mkd
View file

@ -1,4 +1,4 @@
# how to set up gitolite+gitweb+ssh+http-backend ## how to set up gitolite+gitweb+ssh+http-backend
In this document: In this document:

6
doc/gitolite-without-ssh.mkd
View file

@ -11,6 +11,8 @@ be, and usually *isn't*, an actual *unix* username).
[gas]: http://sitaramc.github.com/gitolite/doc/gitolite-and-ssh.html [gas]: http://sitaramc.github.com/gitolite/doc/gitolite-and-ssh.html
<a name="_sidebar_authentication_versus_authorisation"></a>
### sidebar: authentication versus authorisation ### sidebar: authentication versus authorisation
> Just for completeness, I'd like to loosely define these two animals. > Just for completeness, I'd like to loosely define these two animals.
@ -23,6 +25,8 @@ be, and usually *isn't*, an actual *unix* username).
> **Authorisation** is the process of asking what you want to do and > **Authorisation** is the process of asking what you want to do and
> deciding if you're allowed to do it or not. > deciding if you're allowed to do it or not.
<a name="_what_does_gitolite_actually_do"></a>
### what does gitolite actually do ### what does gitolite actually do
With that background, here's the truth about gitolite: With that background, here's the truth about gitolite:
@ -43,6 +47,8 @@ It is also why I often ignore emails and IRC messages that seem like just ssh
issues if I am too busy. I will never ignore core gitolite issues like that, issues if I am too busy. I will never ignore core gitolite issues like that,
of course!] of course!]
<a name="_using_other_authentication_systems_with_gitolite"></a>
### using other authentication systems with gitolite ### using other authentication systems with gitolite
The bottom line in terms of how to invoke gitolite has been described up at The bottom line in terms of how to invoke gitolite has been described up at

6
doc/report-output.mkd
View file

@ -115,9 +115,9 @@ It used to be that the gitolite documentation would say "just use `ssh
git@server`" in the past, because gitolite defaults to the "info" command if git@server`" in the past, because gitolite defaults to the "info" command if
no command is passed. no command is passed.
However, starting with [openssh 5.6][openssh56], this won't work. Openssh However, starting with [openssh 5.6][openssh56], this won't work. The ssh
will now "Kill channel when pty allocation requests fail". This means that client will now "Kill channel when pty allocation requests fail". This means
gitolite is not even invoked; you only get a message about pty allocation that gitolite is not even invoked; you only get a message about pty allocation
failure, followed by "connection closed". failure, followed by "connection closed".
So now you have to use an explicit "info" command, (`ssh git@server info`) or So now you have to use an explicit "info" command, (`ssh git@server info`) or