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

doc/3: made doc for extcmd a little more generic,

Browse source 
with specific sections for commands as needed
This commit is contained in:
Sitaram Chamarty 2010-05-10 07:25:23 +05:30
parent cf9bb98e87
commit 4ad9807225
1 changed files with 22 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

36
doc/3-faq-tips-etc.mkd
View file

@ -503,18 +503,6 @@ You can specify hooks that you want to propagate to all repos, as well as
per-repo "gitconfig" settings. Please see `doc/2-admin.mkd` and per-repo "gitconfig" settings. Please see `doc/2-admin.mkd` and
`conf/example.conf` for details. `conf/example.conf` for details.
<a name="svnserve"></a>
#### svnserve ####
If you are transitioning from SVN to gitolite, and have a lot of users using
public-key authentication with SVN, this feature may be useful to you. Once
you migrate all users' public keys into gitolite, you can set the `$SVNSERVE`
variable in `~/.gitolite.rc` to tie `svnserve` with gitolite's authentication
system. Assuming you installed gitolite to the same user as the one you used
for SVN, SVN connectivity will be retained, and users will be able to use
both SVN and git using the same SSH configuration.
<a name="gitweb"></a> <a name="gitweb"></a>
### helping with gitweb ### helping with gitweb
@ -656,14 +644,34 @@ Please see `doc/4-wildcard-repositories.mkd` for all the details.
Gitolite now has a mechanism for allowing access control for arbitrary Gitolite now has a mechanism for allowing access control for arbitrary
external commands, as long as they are invoked via ssh and present a external commands, as long as they are invoked via ssh and present a
server-side command that contains enough information to make an access control server-side command that contains enough information to make an access control
decision. The first (and only, so far) such command implemented is rsync. decision.
Note that this is incompatible with giving people shell access as described in Note that this is incompatible with giving people shell access as described in
`doc/6-ssh-troubleshooting.mkd` -- people who have shell access are not `doc/6-ssh-troubleshooting.mkd` -- people who have shell access are not
subject to this mechanism (it wouldn't make sense to try and control someone subject to this mechanism (it wouldn't make sense to try and control someone
who has shell access anyway). who has shell access anyway).
Please see the config files (both of them) for examples and usage. In general, external commands require changes in one or both the config files;
the sample files in `conf/` double as documentation, so you should look there
for examples and usage.
Commands implemented so far are:
* rsync
* svnserve (see next section for a brief description; this has been
contributed by Simon and Vladimir)
<a name="svnserve"></a>
##### svnserve
If you are transitioning from SVN to gitolite, and have a lot of users using
public-key authentication with SVN, this feature may be useful to you. Once
you migrate all users' public keys into gitolite, you can set the `$SVNSERVE`
variable in `~/.gitolite.rc` to tie `svnserve` with gitolite's authentication
system. Assuming you installed gitolite to the same user as the one you used
for SVN, SVN connectivity will be retained, and users will be able to use
both SVN and git using the same SSH configuration.
## design choices ## design choices