I'm sorry for the delay in responding. On Wed, 16 Nov 2011, Jonathan Nieder wrote: > Erik Wenzel wrote (http://bugs.debian.org/648561): >> Am 13.11.2011 um 02.19 schrieb Jonathan Nieder: >> >>> The git-daemon(1) manpage describes git daemon, not gitweb, so I guess >>> you mean that >>> >>> # Do not list projects without git-daemon-export-ok in the >>> # projects list. >>> our $export_ok = "git-daemon-export-ok"; >>> >>> # Do not allow access to projects not listed in the projects >>> # list. >>> our $strict_export = 1; >>> >>> should be the default. >> [...] >> Because I think this is the way a user is expecting the behavior of gitweb. >> As I do. Don't let gitweb overwrite the meaning of "git-daemon-export-ok". >> Just act like git-daemon. Keep it simple and stupid. > > My first thought was that if we could turn back time, it would > probably be best for both git-daemon and gitweb to look for a file > named git-export-ok. In the present world, maybe git-daemon-export-ok > is a good substitute for that. > > What do you think? Should the default in the makefile be changed? If > so, how could we go about it to avoid disturbing existing > installations? (For example, in a system where no repositories have > the export-ok files and "git daemon" is configured to run with > --export-all, the effect would be to make repos suddenly disappear > from the projects list in gitweb. Unpleasant.) I think the best solution would be to leave it up to the tool that manages both git-daemon and git (manages access to git repositories), like e.g. gitolite. It would be this tool that is to be responsible for synchronizing git-daemon and gitweb behavior, i.e. make either both use 'git-daemon-export-ok', or both export all. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html