On Fri, Jul 02, 2010 at 07:38:05AM +0100, Justin B Rye wrote: > Jonathan Wiltshire wrote: > > There are no changes to debian/control, although I'm not sure about the > > section talking of "dedication"; I'm hoping somebody will give me some > > ideas about that. Of course, I clearly didn't read the control file very clearly... sorry about that! > > --- ../gitolite.old/debian/templates 2010-07-01 19:56:02.000000000 +0100 > > +++ debian/templates 2010-07-01 20:17:23.000000000 +0100 > > @@ -1,22 +1,24 @@ > > Template: gitolite/gituser > > Type: string > > Default: gitolite > > -_Description: The name of the system user to create: > > +_Description: System user to use: > > > > It might already be created. > > Overused "use". Replace it with some extra context: > > _Description: System username for gitolite: Ack > > Template: gitolite/adminkey > > Type: string > > +_Description: Administrator's SSH key: > > Please specify the key of the user that will administer the access > > + configuration of gitolite. > > + . > > + The installer can accept the SSH public key directly, or the path to a file > > + containing it. If blank, the installer will not configure gitolite and it > > + must be set up manually. > > > > Keep the second person out again. > > Ditto "the installer" (and the dangling modifier "if blank"): > > This can be either the SSH public key itself, or the path to a file > containing it. If it is blank, gitolite will be left unconfigured and > must be set up manually. Ack. > In the control file: > > Package: gitolite > > Architecture: all > > Depends: git (>= 1:1.7.0.4) | git-core (>= 1:1.6.2), perl (>= 5.6.0-16), > > openssh-server | ssh-server, debconf (>= 0.5) | debconf-2.0, adduser > > Suggests: git-daemon-run, gitweb > > Description: ssh-based gatekeeper for git repositories > SSH > > Gitolite is an ssh-based gatekeeper for a server that hosts many git > SSH > > repositories, and that needs access control of some sort. > > How about turning that round as "Gitolite is an SSH-based gatekeeper > providing access control for a server that hosts many git > repositories"? > > > Without gitolite, > > each developer needing to push to one of the repositories hosted will need a > would > > (Unix) userid and password on that server; > > Just say: > user account on the server; > > > gitolite let you do that just using > lets > > ssh public keys tied to a single, common, user that hosts all the > SSH > > repositories. > > Or say: > gitolite replaces this with SSH > public keys tied to a single user that hosts all the repositories. > > > . > > What makes gitolite unique is its dedication: Its primary target is corporate > > environments where the ability to restrict who can push to what branch is also > > important. It has grown beyond that initial motivation to write it and > > acquired several other neat features that you can find described in the main > > README. > > "Dedication" is a slightly odd choice of word... but it's hard to > find a direct replacement. Perhaps instead of focussing on the > project's historical development we could import the list of neat > features from that README: > > Gitolite can restrict who can read (clone/fetch) from or write > (push) to a repository, and who can push to what branch or tag - an > important issue in corporate environments. Other features include: > * access control by branch-name or by modified file/directory; > * per-developer "personal namespace" prefixes; > * simple but powerful configuration file syntax (with validation); > * config files (and authority for maintaining them) can be split; > * easy integration with gitweb; > * comprehensive logging; > * easy migration from gitosis. I like the text from README and all your other suggestions included. Updated patch attached. -- Jonathan Wiltshire 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Attachment:
patch.gz
Description: Binary data
Attachment:
signature.asc
Description: Digital signature