Well, something even more outrageous than deny rules and path-based
limits came along, so I decided that "rebel" was actually quite
"conformist" in comparision ;-)
Jokes apart, the fact is that the access control rules, even when using
deny rules and path-limits, are still *auditable*. Which means it is
good enough for "corporate use".
[The stuff that I'm working on now takes away the auditability aspect --
individual users can "own" repos, create rules for themselves, etc.
So let's just say that is the basis of distinguishing "master" now.]
Summary: much as I did not want to use "excludes", I guess if we don't put the
code in "master" it's OK to at least *write* (and test) the code!
See the example config file for how to use it.
See "design choices" section in the "faq, tips, etc" document for how it
works.
I don't have a use for "@all" at all (pun not intended!) other than the
"testing" repo, but <teemu dot matilainen at iki dot fi> sent in a patch
to mark those repos with "R" and "W" in the permissions list, and I
started thinking about it.
This could actually be useful if we *differentiated* such access from
normal (explicit username) access. From the "corporate environment"
angle, it would be nice if a project manager could quickly check if any
of his projects have erroneously been made accessible by @all.
So what we do now is print "@" in the corresponding column if "@all" has
the corresponding access.
Also, when someone has access both as himself *and* via @all, we print
the "@"; printing the "R" or "W" would hide the "@", and wouldn't
correctly satisfy the use case described above.
- it appears that what we call $repo_base, gitweb already needs as
$projectroot
- allow read of repos defined as readable by @all
plus some minor declaration changes to make the sample code work as is
(thanks to teemu dot matilainen at iki dot fi)
- added comments to easy install to help do it manually
- README: some stuff moved to tips doc, brief summary of extras
(over gitosis) added
- INSTALL: major revamp, easy install and manual install,
much shorter and much more readable!
plus other docs changed as needed, and updated the tips doc to roll in
some details from "update.mkd" in the "ml" branch
- detect/warn git version < 1.6.2
- create documentation with details on client-side workaround
- change the "git init --bare" to (older) "git --bare init", since the old
syntax still works anyway
