{"thread":{"id":"27326","subject":"[PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","startedAt":"2011-05-11T19:21:04Z","lastAt":"2011-05-15T10:34:28Z","messageCount":11,"participants":["Drew Northup","Jonathan Nieder","Jakub Narebski","J.H."],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"167685","messageId":"1305141664.30104.11.camel@drew-northup.unet.maine.edu","threadId":"27326","inReplyTo":null,"subject":"[PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-05-11T19:21:04Z","receivedAt":"2011-05-11T19:21:04Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"This is a work in progress. Much of what is in it has been pulled\ndirectly from the README and INSTALL files of gitweb. No effort has yet\nbeen made to de-duplicate any of this.\n\nTODO:\n * Clean up README and INSTALL files\n * Add Makefile rules to build man / HTML pages.\n * Remove or rephrase redundant portions of original documentation\n * A lot more...\n---\n\nNotes:\nThere ARE INTENTIONAL WHITESPACE ERRORS (Yuck!) to make asciidoc happy. :-(\n\nI have been compiling this with a hand-made test-script into both manpage and\nHTML formats during my testing. It was made by observing what make was doing\non my platform @home (Slackware 13.0 currently).\n\nThis is not quite ready for the big time, so I expect (and hope for) lots of\ncriticism (of the constructive kind?).\n\nIf you don't really need (or want) to be on the CC list let me know. You were\nin the output of 'git blame'....\n\n gitweb/gitweb.conf.txt | 294 ++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 294 insertions(+), 0 deletions(-)\n create mode 100644 gitweb/gitweb.conf.txt\n\ndiff --git a/gitweb/gitweb.conf.txt b/gitweb/gitweb.conf.txt\nnew file mode 100644\nindex 0000000..c14847a\n--- /dev/null\n+++ b/gitweb/gitweb.conf.txt\n@@ -0,0 +1,294 @@\n+gitweb.conf(5)\n+==============\n+\n+NAME\n+----\n+gitweb.conf - Gitweb configuration file\n+\n+SYNOPSIS\n+--------\n+/etc/gitweb.conf\n+\n+DESCRIPTION\n+-----------\n+'Gitweb' is a CGI application for viewing Git repositories over the web. The\n+configuration file is used to override the default settings that were built\n+into gitweb at the time Git itself was compiled. While one could just alter\n+the configuration settings in the gitweb CGI itself, those changes would be\n+lost upon upgrade. Configuration settings my also be placed into a file in\n+the same directory as the CGI script with the default name\n+`gitweb_config.perl` – allowing one to have multiple gitweb instances\n+with different configurations by the use of symlinks.\n+\n+\n+DISCUSSION\n+----------\n+\n+The location of `gitweb.conf` is defined at compile time using the\n+configuration value `GITWEB_CONFIG_SYSTEM` and defaults to /etc/gitweb.conf.\n+The name of the per-instance configuration file is defined in gitweb by\n+`GITWEB_CONFIG`.\n+\n+*NOTE:* Values defined in the per-instance configuration file override both\n+values found in the gitweb CGI as well as values found in the sytem-wide\n+gitweb.conf file.\n+\n+The syntax of the configuration files is that of PERL, as these files are\n+indeed handled as fragments of PERL code (the language that gitweb itself is\n+written in). Variables may be set using \"'our $variable = value'\"; text from\n+\"#\" character until the end of a line is ignored. See the perlsyn(1) man page\n+for more information.\n+\n+One good reason to take advatage of the system-wide and local gitweb\n+configuration files is that not all settings may be set up directly in the CGI\n+itself. Optional features – defined using the '%features' variable\n+– must be set in one of the two configuration files.\n+\n+CONFIGURATION SETTINGS\n+----------------------\n+Standard Options\n+~~~~~~~~~~~~~~~~~\n+The following are not typically set or overridden at build time:\n+\n+$GIT::\n+\tCore git executable to use. By default set to `$GIT_BINDIR/git`, which\n+\tin turn is by default set to `$(bindir)/git`. If you use git from binary\n+\tpackage, set this to \"/usr/bin/git\". This can just be \"git\" if your\n+\twebserver has a sensible PATH. If you have multiple git versions installed\n+\tit can be used to choose which one to use.\n+$version::\n+\tGitweb version, set automatically when creating gitweb.cgi from\n+\tgitweb.perl. You might want to modify it if you are running modified\n+\tgitweb.\n+$projectroot::\n+\tAbsolute filesystem path which will be prepended to project path;\n+\tthe path to repository is `$projectroot/$project`. Set to\n+\t`$GITWEB_PROJECTROOT` during installation. This variable has to be\n+\tset correctly for gitweb to find repositories.\n+$projects_list::\n+\tSource of projects list, either directory to scan, or text file\n+\twith list of repositories (in the \"` SP\n+\t`\" line format; actually there can be\n+\tany sequence of whitespace in place of space (SP)). Set to\n+\t`$GITWEB_LIST` during installation. If empty, `$projectroot` is used\n+\tto scan for repositories.\n+$my_url, $my_uri::\n+\tFull URL and absolute URL of gitweb script;\n+\tin earlier versions of gitweb you might have need to set those\n+\tvariables, now there should be no need to do it. See\n+\t`$per_request_config` if you need to set them still.\n+$base_url::\n+\tBase URL for relative URLs in pages generated by gitweb,\n+\t(e.g. `$logo`, `$favicon`, `@stylesheets` if they are relative URLs),\n+\tneeded and used only for URLs with nonempty PATH_INFO via\n+\t''. Usually gitweb sets its value correctly,\n+\tand there is no need to set this variable, e.g. to $my_uri or \"/\".\n+\tSee `$per_request_config` if you need to set it anyway.\n+$home_link::\n+\tTarget of the home link on top of all pages (the first part of view\n+\t\"breadcrumbs\"). By default set to absolute URI of a page ($my_uri).\n+@stylesheets::\n+\tList of URIs of stylesheets (relative to base URI of a page). You\n+\tmight specify more than one stylesheet, for example use gitweb.css\n+\tas base, with site specific modifications in separate stylesheet\n+\tto make it easier to upgrade gitweb. You can add a `site` stylesheet\n+\tfor example by using +\n+\t\t`push @stylesheets, \"gitweb-site.css\";` + \n+\tin the gitweb config file.\n+$logo_url, $logo_label::\n+\tURI and label (title) of GIT logo link (or your site logo, if you choose\n+\tto use different logo image). By default they point to git homepage;\n+\tin the past they pointed to git documentation at www.kernel.org.\n+$projects_list_description_width::\n+\tThe width (in characters) of the projects list \"Description\" column.\n+\tLonger descriptions will be cut (trying to cut at word boundary);\n+\tfull description is available as 'title' attribute (usually shown on\n+\tmouseover). By default set to 25, which might be too small if you\n+\tuse long project descriptions.\n+@git_base_url_list::\n+\tList of git base URLs used for URL to where fetch project from, shown\n+\tin project summary page. Full URL is \"`$git_base_url/$project`\".\n+\tYou can setup multiple base URLs (for example one for git:// protocol\n+\taccess, and one for http:// \"dumb\" protocol access). Note that per\n+\trepository configuration in 'cloneurl' file, or as values of gitweb.url\n+\tproject config.\n+$default_blob_plain_mimetype::\n+\tDefault mimetype for blob_plain (raw) view, if mimetype checking\n+\tdoesn't result in some other type; by default 'text/plain'.\n+$default_text_plain_charset::\n+\tDefault charset for text files. If not set, web server configuration\n+\twould be used.\n+$mimetypes_file::\n+\tFile to use for (filename extension based) guessing of MIME types before\n+\ttrying /etc/mime.types. Path, if relative, is taken currently as\n+\trelative to the current git repository.\n+$fallback_encoding::\n+\tGitweb assumes this charset if line contains non-UTF-8 characters.\n+\tFallback decoding is used without error checking, so it can be even\n+\t'utf-8'. Value must be valid encoding; see Encoding::Supported(3pm) man\n+\tpage for a list. By default 'latin1', aka. 'iso-8859-1'.\n+@diff_opts::\n+\tRename detection options for git-diff and git-diff-tree. By default\n+\t(\\'-M'); set it to (\\'-C') or (\\'-C', \\'-C') to also detect copies, or\n+\tset it to () if you don't want to have renames detection.\n+$prevent_xss::\n+\tIf true, some gitweb features are disabled to prevent content in\n+\trepositories from launching cross-site scripting (XSS) attacks. Set this\n+\tto true if you don't trust the content of your repositories.\n+[Default: false].\n+$maxload::\n+\tUsed to set the maximum load that we will still respond to gitweb queries.\n+\tIf server load exceed this value then return \"503 Service Unavailable\"\n+\terror. Server load is taken to be 0 if gitweb cannot determine its value.\n+\tSet it to undefined value to turn it off. [Default: 300]\n+$highlight_bin::\n+\tPath to the highlight executable to use (must be the one from\n+\thttp://www.andre-simon.de due to assumptions about parameters and output).\n+\tUseful if highlight is not installed on your webserver's PATH.\n+\t[Default: highlight]\n+$per_request_config::\n+\tIf set to code reference, it would be run once per each request. You can\n+\tset parts of configuration that change per session, e.g. by setting it to +\n+\t\t`sub { $ENV{GL_USER} = $cgi->remote_user || \"gitweb\"; }` + \n+\tOtherwise it is treated as boolean value: if true gitweb would process\n+\tconfig file once per request, if false it would process config file only\n+\tonce. Note: $my_url, $my_uri, and $base_url are overwritten with\n+\ttheir default values before every request, so if you want to change\n+\tthem, be sure to set this variable to true or a code reference effecting\n+\tthe desired changes. [Default: true]\n+\n+Configuration Options Often Set at Compile Time\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+These configuration variables are often specified at compile time and are\n+defined by default in the gitweb CGI itself:\n+\n+GIT_BINDIR::\n+\tPoints where to find the git executable. You should set it up to\n+\tthe place where the git binary was installed (usually /usr/bin) if you\n+\tdon't install git from sources together with gitweb. [Default: $(bindir)]\n+GITWEB_SITENAME::\n+\tShown in the title of all generated pages, defaults to the server name\n+\t(SERVER_NAME CGI environment variable) if not set. [No default]\n+GITWEB_PROJECTROOT::\n+\tThe root directory for all projects shown by gitweb. Must be set\n+\tcorrectly for gitweb to find repositories to display. See also\n+\t\"Gitweb repositories\" in the INSTALL file for gitweb. [Default: /pub/git]\n+GITWEB_PROJECT_MAXDEPTH::\n+\tThe filesystem traversing limit for getting the project list; the number\n+\tis taken as depth relative to the projectroot. It is used when\n+\tGITWEB_LIST is a directory (or is not set; then project root is used).\n+\tIs is meant to speed up project listing on large work trees by limiting\n+\tsearch depth. [Default: 2007]\n+GITWEB_LIST::\n+\tPoints to a directory to scan for projects (defaults to project root\n+\tif not set / if empty) or to a file with explicit listing of projects\n+\t(together with projects' ownership). See \"Generating projects list\n+\tusing gitweb\" in INSTALL file for gitweb to find out how to generate\n+\tsuch file from scan of a directory. [No default, which means use root\n+\tdirectory for projects]\n+GITWEB_EXPORT_OK::\n+\tShow repository only if this file exists (in repository). Only\n+\teffective if this variable evaluates to true. [No default / Not set]\n+GITWEB_STRICT_EXPORT::\n+\tOnly allow viewing of repositories also shown on the overview page.\n+\tThis for example makes GITWEB_EXPORT_OK to decide if repository is\n+\tavailable and not only if it is shown. If GITWEB_LIST points to\n+\tfile with list of project, only those repositories listed would be\n+\tavailable for gitweb. [No default]\n+GITWEB_HOMETEXT::\n+\tPoints to an .html file which is included on the gitweb project\n+\toverview page ('projects_list' view), if it exists. Relative to\n+\tgitweb.cgi script. [Default: indextext.html]\n+GITWEB_SITE_HEADER::\n+\tFilename of html text to include at top of each page. Relative to\n+\tgitweb.cgi script. [No default]\n+GITWEB_SITE_FOOTER::\n+\tFilename of html text to include at bottom of each page. Relative to\n+\tgitweb.cgi script. [No default]\n+GITWEB_HOME_LINK_STR::\n+\tString of the home link on top of all pages, leading to $home_link\n+\t(usually main gitweb page, which means projects list). Used as first\n+\tpart of gitweb view \"breadcrumb trail\": / / .\n+\t[Default: projects]\n+GITWEB_SITENAME::\n+\tName of your site or organization to appear in page titles. Set it\n+\tto something descriptive for clearer bookmarks etc. If not set\n+\t(if empty) gitweb uses \"$SERVER_NAME Git\", or \"Untitled Git\" if\n+\tSERVER_NAME CGI environment variable is not set (e.g. if running\n+\tgitweb as standalone script). [No default]\n+GITWEB_BASE_URL::\n+\tGit base URLs used for URL to where fetch project from, i.e. full\n+\tURL is \"$git_base_url/$project\". Shown on projects summary page.\n+\tRepository URL for project can be also configured per repository; this\n+\ttakes precedence over URLs composed from base URL and a project name.\n+\tNote that you can setup multiple base URLs (for example one for\n+\tgit:// protocol access, another for http:// access) from the gitweb\n+\tconfig file. [No default]\n+GITWEB_CSS::\n+\tPoints to the location where you put gitweb.css on your web server\n+\t(or to be more generic, the URI of gitweb stylesheet). Relative to the\n+\tbase URI of gitweb. Note that you can setup multiple stylesheets from\n+\tthe gitweb config file. [Default: static/gitweb.css (or\n+\tstatic/gitweb.min.css if the CSSMIN variable is defined / CSS minifier\n+\tis used)]\n+GITWEB_LOGO::\n+\tPoints to the location where you put git-logo.png on your web server\n+\t(or to be more generic URI of logo, 72x27 size, displayed in top right\n+\tcorner of each gitweb page, and used as logo for Atom feed). Relative\n+\tto base URI of gitweb. [Default: static/git-logo.png]\n+GITWEB_FAVICON::\n+\tPoints to the location where you put git-favicon.png on your web server\n+\t(or to be more generic URI of favicon, assumed to be image/png type;\n+\tweb browsers that support favicons (website icons) may display them\n+\tin the browser's URL bar and next to site name in bookmarks). Relative\n+\tto base URI of gitweb. [Default: static/git-favicon.png]\n+GITWEB_JS::\n+\tPoints to the location where you put gitweb.js on your web server\n+\t(or to be more generic URI of JavaScript code used by gitweb).\n+\tRelative to base URI of gitweb. [Default: static/gitweb.js (or\n+\tstatic/gitweb.min.js if JSMIN build variable is defined / JavaScript\n+\tminifier is used)]\n+HIGHLIGHT_BIN::\n+\tPath to the highlight executable to use (must be the one from\n+\thttp://www.andre-simon.de due to assumptions about parameters and output).\n+\tUseful if highlight is not installed on your webserver's PATH.\n+\t[Default: highlight]\n+\n+\n+Configuration File Example\n+~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+To enable blame, pickaxe search, and snapshot support, while allowing\n+individual projects to turn them off, put the following in your\n+GITWEB_CONFIG file:\n+\n+ $feature{'blame'}{'default'} = [1];\n+ $feature{'blame'}{'override'} = 1;\n+\n+ $feature{'pickaxe'}{'default'} = [1];\n+ $feature{'pickaxe'}{'override'} = 1;\n+\n+ $feature{'snapshot'}{'default'} = ['zip', 'tgz'];\n+ $feature{'snapshot'}{'override'} = 1;\n+\n+If you allow overriding for the snapshot feature, you can specify which\n+snapshot formats are globally disabled. You can also add any command line\n+options you want (such as setting the compression level). For instance,\n+you can disable Zip compressed snapshots and set GZip to run at level 6 by\n+adding the following lines to your $GITWEB_CONFIG:\n+\n+ $known_snapshot_formats{'zip'}{'disabled'} = 1;\n+ $known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6'];\n+\n+FILES\n+-----\n+/etc/gitweb.conf, gitweb_config.perl\n+\n+\n+SEE ALSO\n+--------\n+In Progress\n+\n+GIT\n+---\n+Part of the linkgit:git[1] suite\n-- \n1.7.4.1\n"},{"id":"167719","messageId":"20110512105325.GA13490@elie","threadId":"27326","inReplyTo":"1305141664.30104.11.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-12T10:53:25Z","receivedAt":"2011-05-12T10:53:25Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Drew,\n\nDrew Northup wrote:\n\n> This is a work in progress. Much of what is in it has been pulled\n> directly from the README and INSTALL files of gitweb. No effort has yet\n> been made to de-duplicate any of this.\n\nThanks!\n\n> TODO:\n> * Clean up README and INSTALL files\n> * Add Makefile rules to build man / HTML pages.\n> * Remove or rephrase redundant portions of original documentation\n> * A lot more...\n\nI agree with this TODO list. :) It should be possible to reuse rules from\nDocumentation/Makefile if you put this under Documentation/. gitweb already\nkeeps its tests under t/ for convenience; I think it's okay if it\nputs some documentation under Documentation/.\n\n> If you don't really need (or want) to be on the CC list let me know. You were\n> in the output of 'git blame'....\n\nI've aggressively culled the cc list for my reply to avoid punishing\nkind people who improved gitweb by swamping them with mail.\n\n> --- /dev/null\n> +++ b/gitweb/gitweb.conf.txt\n> @@ -0,0 +1,294 @@\n> +gitweb.conf(5)\n> +==============\n> +\n> +NAME\n> +----\n> +gitweb.conf - Gitweb configuration file\n\nIt sounds like a tautology. Maybe \"configuration for git's web\ninterface\"? Except that there is at least one other web interface for\ngit (cgit). Hm.\n\n> +\n> +SYNOPSIS\n> +--------\n> +/etc/gitweb.conf\n\ngitweb will also look for gitweb_config.perl along @INC, and\nthe $GITWEB_CONFIG and $GITWEB_CONFIG_SYSTEM envvars can override\nthese paths.\n\n> +\n> +DESCRIPTION\n> +-----------\n> +'Gitweb' is a CGI application for viewing Git repositories over the web. The\n> +configuration file is used to override the default settings that were built\n> +into gitweb at the time Git itself was compiled.\n\nStyle nit: I'd launch into what gitweb.conf contains right away, like\nso:\n\n\tThe gitweb CGI script for viewing Git repositories over the\n\tweb uses a perl script fragment as its configuration file.\n\tYou can set variables using \"our $variable = value\"; text\n\tfrom a \"#\" character until the end of a line is ignored.\n\tSee *perlsyn*(1) for details.\n\n\tThe configuration file is used to override the default\n\tsettings that were built into gitweb at the time it was\n\tinstalled.\n\n> While one could just alter\n> +the configuration settings in the gitweb CGI itself, those changes would be\n> +lost upon upgrade. Configuration settings my also be placed into a file in\n> +the same directory as the CGI script with the default name\n> +`gitweb_config.perl` – allowing one to have multiple gitweb instances\n> +with different configurations by the use of symlinks.\n\nGood point; I hadn't thought about the multiple-configurations use case.\n\n> +DISCUSSION\n> +----------\n> +\n> +The location of `gitweb.conf` is defined at compile time using the\n> +configuration value `GITWEB_CONFIG_SYSTEM` and defaults to /etc/gitweb.conf.\n> +The name of the per-instance configuration file is defined in gitweb by\n> +`GITWEB_CONFIG`.\n> +\n> +*NOTE:* Values defined in the per-instance configuration file override both\n> +values found in the gitweb CGI as well as values found in the sytem-wide\n> +gitweb.conf file.\n\nDoesn't gitweb_config.perl suppress the effect of gitweb.conf altogether?\n\n> +\n> +The syntax of the configuration files is that of PERL, as these files are\n> +indeed handled as fragments of PERL code (the language that gitweb itself is\n> +written in). Variables may be set using \"'our $variable = value'\"; text from\n> +\"#\" character until the end of a line is ignored. See the perlsyn(1) man page\n> +for more information.\n\nThe perl manual spells the name of that language as \"Perl\". I think\nit might make sense to mention the syntax earlier, since it makes it\nless daunting to dive into the file right away.\n\n> +\n> +One good reason to take advatage of the system-wide and local gitweb\n> +configuration files is that not all settings may be set up directly in the CGI\n> +itself. Optional features – defined using the '%features' variable\n> +– must be set in one of the two configuration files.\n\nI don't follow what this paragraph is saying. Is the idea something\nlike this?\n\n\tThe default configuration with no configuration file at all\n\tmay work perfectly well for some installations. Still, a\n\tconfiguration file is useful for customizing or tweaking the\n\tbehavior of gitweb in many ways, and some optional features\n\twill not be present unless explicitly enabled using the\n\tconfigurable %features variable.\n\n> +\n> +CONFIGURATION SETTINGS\n> +----------------------\n\nConfiguration settings as opposed to non-configuration settings? :)\n\nMaybe something like\n\n\tVARIABLES\n\t---------\n\nwould be clearer.\n\n> +Standard Options\n> +~~~~~~~~~~~~~~~~~\n> +The following are not typically set or overridden at build time:\n\nI suppose the above is a paraphrase of\n\n (with the exception of $projectroot and $projects_list this list does\n not include variables usually directly set during build):\n\nbut this shortened version just left me confused (why do I care\nwhich variables people typically override at build time?). The\noriginal suggests that for build-time configuration I should look\nelsewhere, which made it a little clearer to me.\n\n> +\n> +$GIT::\n> +\tCore git executable to use.\n\nAh, what a variable to start with. Maybe this can be snuck later in\nthe list somehow, so the reader can get to juicier bits first.\n\n> +$version::\n> +\tGitweb version, set automatically when creating gitweb.cgi from\n> +\tgitweb.perl. You might want to modify it if you are running modified\n> +\tgitweb.\n\nWhy would I want to set this in the config file? Wouldn't my patch to\ngitweb.cgi modify $version?\n\n> +$projectroot::\n> +\tAbsolute filesystem path which will be prepended to project path;\n> +\tthe path to repository is `$projectroot/$project`. Set to\n> +\t`$GITWEB_PROJECTROOT` during installation. This variable has to be\n> +\tset correctly for gitweb to find repositories.\n\nThis is an interesting one. The description is not so clear to me ---\nI guess the idea is that if $projectroot = \"/srv/git\" then\n\n http://path/to/gitweb/installation/?p=foo/bar.git\n\nwill map to /srv/git/foo/bar.git on the filesystem (and likewise for\nPATH_INFO based URLs)?\n\n> +$projects_list::\n> +\tSource of projects list, either directory to scan, or text file\n> +\twith list of repositories (in the \"` SP\n> +\t`\" line format; actually there can be\n> +\tany sequence of whitespace in place of space (SP)). Set to\n> +\t`$GITWEB_LIST` during installation. If empty, `$projectroot` is used\n> +\tto scan for repositories.\n\nMaybe clearer to emphasize the kinds of values it takes first? That\nis:\n\n\tSpace-separated list of paths to files listing projects or\n\tdirectories to be scanned for projects. Project list files\n\tshould list one project per line, with each line having the\n\tformat \"` SP\n\t`. The default is determined\n\tby the GITWEB_LIST makefile variable at installation time.\n\tIf this variable is empty, gitweb will fall back to scanning\n\tthe `$projectroot` for repositories.\n\n[...]\n> +Configuration Options Often Set at Compile Time\n> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +These configuration variables are often specified at compile time and are\n> +defined by default in the gitweb CGI itself:\n> +\n> +GIT_BINDIR::\n> +\tPoints where to find the git executable. You should set it up to\n> +\tthe place where the git binary was installed (usually /usr/bin) if you\n> +\tdon't install git from sources together with gitweb. [Default: $(bindir)]\n\nI don't think there is a GIT_BINDIR configuration variable, though\nthere is a makefile variable with that name used to determine the\ndefault value of $GIT.\n\nLikewise for the others. I don't think they belong in the manpage.\n\n[...]\n> +Configuration File Example\n> +~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nAh, glad you did this. I would make \"Example\" or \"Examples\" a\nseparate top-level section so they are easier to find.\n\nOk, that's all for now. Still, hope that helps.\n\nRegards,\nJonathan\n"},{"id":"167738","messageId":"201105121701.26547.jnareb@gmail.com","threadId":"27326","inReplyTo":"20110512105325.GA13490@elie","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-12T15:01:25Z","receivedAt":"2011-05-12T15:01:25Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 12 May 2011, Jonathan Nieder wrote:\n> Drew Northup wrote:\n> \n> > This is a work in progress. Much of what is in it has been pulled\n> > directly from the README and INSTALL files of gitweb. No effort has yet\n> > been made to de-duplicate any of this.\n\nWhile it might be a good idea to split main part of gitweb/README into\ngitweb.conf.txt (documenting configuration), and perhaps also separate\ngitweb.txt (main page for gitweb, like SVN::Web manpage), I don't think\nthat much of gitweb/INSTALL should be moved.\n\n> > TODO:\n> > * Clean up README and INSTALL files\n> > * Add Makefile rules to build man / HTML pages.\n> > * Remove or rephrase redundant portions of original documentation\n> > * A lot more...\n> \n> I agree with this TODO list. :) It should be possible to reuse rules from\n> Documentation/Makefile if you put this under Documentation/. gitweb already\n> keeps its tests under t/ for convenience; I think it's okay if it\n> puts some documentation under Documentation/.\n\nNote that git-gui and gitk both also keep their manpages in Documentation/\nas Documentation/git-gui.txt and Documentation/gitk.txt\n\nWe can add \"doc\" target to gitweb/Makefile, which would delegate work to\n../Documentation/Makefile, similarly to existing \"test\" target in\ngitweb/Makefile.\n\n\n> > --- /dev/null\n> > +++ b/gitweb/gitweb.conf.txt\n> > @@ -0,0 +1,294 @@\n> > +gitweb.conf(5)\n> > +==============\n> > +\n> > +NAME\n> > +----\n> > +gitweb.conf - Gitweb configuration file\n> \n> It sounds like a tautology. Maybe \"configuration for git's web\n> interface\"? Except that there is at least one other web interface for\n> git (cgit). Hm.\n\nLet's take a look how it is done in other section 5 manpages documenting\nconfiguration files:\n\n dhclient.conf(5): dhclient.conf - DHCP client configuration file\n ldap.conf(5): ldap.conf, .ldaprc - ldap configuration file\n yum.con(5): yum.conf - Configuration file for yum(8).\n\nSo it is not much of tautology, I think.\n \n> > +\n> > +SYNOPSIS\n> > +--------\n> > +/etc/gitweb.conf\n\nI'd say\n\n +SYNOPSIS\n +--------\n +gitweb_conf.perl\n +/etc/gitweb.conf\n\nor\n\n +SYNOPSIS\n +--------\n +$GITWEBDIR/gitweb_conf.perl\n +/etc/gitweb.conf\n \n> gitweb will also look for gitweb_config.perl along @INC, and\n> the $GITWEB_CONFIG and $GITWEB_CONFIG_SYSTEM envvars can override\n> these paths.\n\nI think that we don't need to describe envvars in synopsis, but we\nshould have per-gitweb configuration file (gitweb_conf.perl) in\n\"Synopsis\" section.\n \n> > +\n> > +DESCRIPTION\n> > +-----------\n> > +'Gitweb' is a CGI application for viewing Git repositories over the web. The\n> > +configuration file is used to override the default settings that were built\n> > +into gitweb at the time Git itself was compiled.\n> \n> Style nit: I'd launch into what gitweb.conf contains right away, like\n> so:\n> \n> \tThe gitweb CGI script for viewing Git repositories over the\n> \tweb uses a perl script fragment as its configuration file.\n> \tYou can set variables using \"our $variable = value\"; text\n> \tfrom a \"#\" character until the end of a line is ignored.\n> \tSee *perlsyn*(1) for details.\n> \n> \tThe configuration file is used to override the default\n> \tsettings that were built into gitweb at the time it was\n> \tinstalled.\n\nI agree with Jonathan here.\n \n> > +While one could just alter\n> > +the configuration settings in the gitweb CGI itself, those changes would be\n> > +lost upon upgrade. Configuration settings my also be placed into a file in\n> > +the same directory as the CGI script with the default name\n> > +`gitweb_config.perl` – allowing one to have multiple gitweb instances\n> > +with different configurations by the use of symlinks.\n> \n> Good point; I hadn't thought about the multiple-configurations use case.\n\nRight.\n\n> > +DISCUSSION\n> > +----------\n> > +\n> > +The location of `gitweb.conf` is defined at compile time using the\n> > +configuration value `GITWEB_CONFIG_SYSTEM` and defaults to /etc/gitweb.conf.\n> > +The name of the per-instance configuration file is defined in gitweb by\n> > +`GITWEB_CONFIG`.\n> > +\n> > +*NOTE:* Values defined in the per-instance configuration file override both\n> > +values found in the gitweb CGI as well as values found in the sytem-wide\n> > +gitweb.conf file.\n> \n> Doesn't gitweb_config.perl suppress the effect of gitweb.conf altogether?\n\nYes it does.\n\nThe sequence is as following:\n\n1. Per-gitweb configuration file is given by envvar GITWEB_CONFIG; if it\n is not set, then by default gitweb_conf.perl is used (one can override\n the latter name via build-time configuration variable GITWEB_CONFIG).\n Note: relative path means relative to installed gitweb.cgi script.\n\n2. System-wide configuration file is given by envvar GITWEB_CONFIG_SYSTEM;\n if it is not set, then by default /etc/gitweb.conf is used (one can\n override the latter name via build-time configuration variable\n GITWEB_CONFIG_SYSTEM). Note: sysconfdir is not taken into account\n by gitweb/Makefile, but perhaps it should.\n \nGitweb obtains configuration data from the following sources in the\nfollowing order:\n\n 1. gitweb's installation configuration file ($GITWEBDIR/gitweb_conf.perl)\n 2. system-wide configuration file (/etc/gitweb.conf)\n\nFirst existing config file is used.\n\n\nSidenote: we could replace GITWE_CONFIG and GITWEB_CONFIG_SYSTEM in \ngitweb.conf.txt during building documentation.\n\n> > +\n> > +The syntax of the configuration files is that of PERL, as these files are\n> > +indeed handled as fragments of PERL code (the language that gitweb itself is\n> > +written in). Variables may be set using \"'our $variable = value'\"; text from\n> > +\"#\" character until the end of a line is ignored. See the perlsyn(1) man page\n> > +for more information.\n\nActually using 'our $variable = ' is a safety check: if newer gitweb\ndoes no longer use given value, using 'our' wouldn't cause errors.\n \n> The perl manual spells the name of that language as \"Perl\". I think\n> it might make sense to mention the syntax earlier, since it makes it\n> less daunting to dive into the file right away.\n\nI think it might be good idea to provide bare-bones example here.\n \n> > +\n> > +One good reason to take advatage of the system-wide and local gitweb\n> > +configuration files is that not all settings may be set up directly in the CGI\n> > +itself. Optional features – defined using the '%features' variable\n> > +– must be set in one of the two configuration files.\n> \n> I don't follow what this paragraph is saying. Is the idea something\n> like this?\n> \n> \tThe default configuration with no configuration file at all\n> \tmay work perfectly well for some installations. Still, a\n> \tconfiguration file is useful for customizing or tweaking the\n> \tbehavior of gitweb in many ways, and some optional features\n> \twill not be present unless explicitly enabled using the\n> \tconfigurable %features variable.\n\nI think the idea is that not all of configuration knobs can be tweaked\nduring \"compile\"-time. Some require setting from configuration file.\n\nNote: we probably want to mention gitweb/config.mak or config.mak somewhere\nas place to save build-time configuration, persistently.\n\n> > +\n> > +CONFIGURATION SETTINGS\n> > +----------------------\n> \n> Configuration settings as opposed to non-configuration settings? :)\n> \n> Maybe something like\n> \n> \tVARIABLES\n> \t---------\n> \n> would be clearer.\n\nPerhaps.\n \n> > +Standard Options\n> > +~~~~~~~~~~~~~~~~~\n> > +The following are not typically set or overridden at build time:\n[...]\n> > +\n> > +$GIT::\n> > +\tCore git executable to use.\n> \n> Ah, what a variable to start with. Maybe this can be snuck later in\n> the list somehow, so the reader can get to juicier bits first.\n\nThis is set at build time, by default to $(bindir)/git\n\n> > +$version::\n> > +\tGitweb version, set automatically when creating gitweb.cgi from\n> > +\tgitweb.perl. You might want to modify it if you are running modified\n> > +\tgitweb.\n> \n> Why would I want to set this in the config file? Wouldn't my patch to\n> gitweb.cgi modify $version?\n\nWell, for running gitweb.perl (not build!) from command line I use\n\n our $version = \"current\";\n\nBut this is I think rare case.\n \n> > +$projectroot::\n> > +\tAbsolute filesystem path which will be prepended to project path;\n> > +\tthe path to repository is `$projectroot/$project`. Set to\n> > +\t`$GITWEB_PROJECTROOT` during installation. This variable has to be\n> > +\tset correctly for gitweb to find repositories.\n> \n> This is an interesting one. The description is not so clear to me ---\n> I guess the idea is that if $projectroot = \"/srv/git\" then\n> \n> http://path/to/gitweb/installation/?p=foo/bar.git\n> \n> will map to /srv/git/foo/bar.git on the filesystem (and likewise for\n> PATH_INFO based URLs)?\n\nYes.\n\n> > +$projects_list::\n> > +\tSource of projects list, either directory to scan, or text file\n> > +\twith list of repositories (in the \"` SP\n> > +\t`\" line format; actually there can be\n> > +\tany sequence of whitespace in place of space (SP)). Set to\n> > +\t`$GITWEB_LIST` during installation. If empty, `$projectroot` is used\n> > +\tto scan for repositories.\n> \n> Maybe clearer to emphasize the kinds of values it takes first? That\n> is:\n> \n> \tSpace-separated list of paths to files listing projects or\n> \tdirectories to be scanned for projects. Project list files\n> \tshould list one project per line, with each line having the\n> \tformat \"` SP\n> \t`. The default is determined\n> \tby the GITWEB_LIST makefile variable at installation time.\n> \tIf this variable is empty, gitweb will fall back to scanning\n> \tthe `$projectroot` for repositories.\n\nI think to not have long wall of text here, we should reference part\nof documentation that explains how gitweb finds repositories, including\nformat of $projects_list file.\n \n> [...]\n> > +Configuration Options Often Set at Compile Time\n> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > +These configuration variables are often specified at compile time and are\n> > +defined by default in the gitweb CGI itself:\n> > +\n> > +GIT_BINDIR::\n> > +\tPoints where to find the git executable. You should set it up to\n> > +\tthe place where the git binary was installed (usually /usr/bin) if you\n> > +\tdon't install git from sources together with gitweb. [Default: $(bindir)]\n> \n> I don't think there is a GIT_BINDIR configuration variable, though\n> there is a makefile variable with that name used to determine the\n> default value of $GIT.\n> \n> Likewise for the others. I don't think they belong in the manpage.\n\nI agree. What is important during build time \"only\" should remain in\ngitweb/INSTALL.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"167748","messageId":"1305219789.24667.64.camel@drew-northup.unet.maine.edu","threadId":"27326","inReplyTo":"201105121701.26547.jnareb@gmail.com","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-05-12T17:03:09Z","receivedAt":"2011-05-12T17:03:09Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Thu, 2011-05-12 at 17:01 +0200, Jakub Narebski wrote:\n> On Thu, 12 May 2011, Jonathan Nieder wrote:\n> > Drew Northup wrote:\n> > \n> > > This is a work in progress. Much of what is in it has been pulled\n> > > directly from the README and INSTALL files of gitweb. No effort has yet\n> > > been made to de-duplicate any of this.\n> \n> While it might be a good idea to split main part of gitweb/README into\n> gitweb.conf.txt (documenting configuration), and perhaps also separate\n> gitweb.txt (main page for gitweb, like SVN::Web manpage), I don't think\n> that much of gitweb/INSTALL should be moved.\n\nThat's pretty much my conclusion as well. I'm focusing solely on the\nconfiguration portion right now. A main page for Gitweb itself will\ndefinitely be useful.\n\n> > > TODO:\n> > > * Clean up README and INSTALL files\n> > > * Add Makefile rules to build man / HTML pages.\n> > > * Remove or rephrase redundant portions of original documentation\n> > > * A lot more...\n> > \n> > I agree with this TODO list. :) It should be possible to reuse rules from\n> > Documentation/Makefile if you put this under Documentation/. gitweb already\n> > keeps its tests under t/ for convenience; I think it's okay if it\n> > puts some documentation under Documentation/.\n> \n> Note that git-gui and gitk both also keep their manpages in Documentation/\n> as Documentation/git-gui.txt and Documentation/gitk.txt\n\nI've been keeping my work in the gitweb directory mostly for\nconvenience. I've put my \"compilation\" script there for testing the\nasciidoc compilation just so that I don't need to mess with make for the\ntime being.\n\n> We can add \"doc\" target to gitweb/Makefile, which would delegate work to\n> ../Documentation/Makefile, similarly to existing \"test\" target in\n> gitweb/Makefile.\n\nThat makes sense to me. Shouldn't be too much work for me to piece that\ntogether when I'm ready.\n\n> > > --- /dev/null\n> > > +++ b/gitweb/gitweb.conf.txt\n> > > @@ -0,0 +1,294 @@\n> > > +gitweb.conf(5)\n> > > +==============\n> > > +\n> > > +NAME\n> > > +----\n> > > +gitweb.conf - Gitweb configuration file\n> > \n> > It sounds like a tautology. Maybe \"configuration for git's web\n> > interface\"? Except that there is at least one other web interface for\n> > git (cgit). Hm.\n> \n> Let's take a look how it is done in other section 5 manpages documenting\n> configuration files:\n> \n> dhclient.conf(5): dhclient.conf - DHCP client configuration file\n> ldap.conf(5): ldap.conf, .ldaprc - ldap configuration file\n> yum.con(5): yum.conf - Configuration file for yum(8).\n> \n> So it is not much of tautology, I think.\n\nI had started with resolv.conf(5) actually. Same idea--concise but\nperhaps not amazingly informative.\n\n> > > +\n> > > +SYNOPSIS\n> > > +--------\n> > > +/etc/gitweb.conf\n> \n> I'd say\n> \n> +SYNOPSIS\n> +--------\n> +gitweb_conf.perl\n> +/etc/gitweb.conf\n> \n> or\n> \n> +SYNOPSIS\n> +--------\n> +$GITWEBDIR/gitweb_conf.perl\n> +/etc/gitweb.conf\n> \n> > gitweb will also look for gitweb_config.perl along @INC, and\n> > the $GITWEB_CONFIG and $GITWEB_CONFIG_SYSTEM envvars can override\n> > these paths.\n> \n> I think that we don't need to describe envvars in synopsis, but we\n> should have per-gitweb configuration file (gitweb_conf.perl) in\n> \"Synopsis\" section.\n\nSounds reasonable to me.\n \n> > > +\n> > > +DESCRIPTION\n> > > +-----------\n> > > +'Gitweb' is a CGI application for viewing Git repositories over the web. The\n> > > +configuration file is used to override the default settings that were built\n> > > +into gitweb at the time Git itself was compiled.\n> > \n> > Style nit: I'd launch into what gitweb.conf contains right away, like\n> > so:\n> > \n> > \tThe gitweb CGI script for viewing Git repositories over the\n> > \tweb uses a perl script fragment as its configuration file.\n> > \tYou can set variables using \"our $variable = value\"; text\n> > \tfrom a \"#\" character until the end of a line is ignored.\n> > \tSee *perlsyn*(1) for details.\n> > \n> > \tThe configuration file is used to override the default\n> > \tsettings that were built into gitweb at the time it was\n> > \tinstalled.\n> \n> I agree with Jonathan here.\n\nComment noted. Perhaps resolv.conf(5) wasn't the best example for\nthis...\n \n> > > +While one could just alter\n> > > +the configuration settings in the gitweb CGI itself, those changes would be\n> > > +lost upon upgrade. Configuration settings my also be placed into a file in\n> > > +the same directory as the CGI script with the default name\n> > > +`gitweb_config.perl` – allowing one to have multiple gitweb instances\n> > > +with different configurations by the use of symlinks.\n> > \n> > Good point; I hadn't thought about the multiple-configurations use case.\n> \n> Right.\n> \n> > > +DISCUSSION\n> > > +----------\n> > > +\n> > > +The location of `gitweb.conf` is defined at compile time using the\n> > > +configuration value `GITWEB_CONFIG_SYSTEM` and defaults to /etc/gitweb.conf.\n> > > +The name of the per-instance configuration file is defined in gitweb by\n> > > +`GITWEB_CONFIG`.\n> > > +\n> > > +*NOTE:* Values defined in the per-instance configuration file override both\n> > > +values found in the gitweb CGI as well as values found in the sytem-wide\n> > > +gitweb.conf file.\n> > \n> > Doesn't gitweb_config.perl suppress the effect of gitweb.conf altogether?\n> \n> Yes it does.\n> \n> The sequence is as following:\n> \n> 1. Per-gitweb configuration file is given by envvar GITWEB_CONFIG; if it\n> is not set, then by default gitweb_conf.perl is used (one can override\n> the latter name via build-time configuration variable GITWEB_CONFIG).\n> Note: relative path means relative to installed gitweb.cgi script.\n> \n> 2. System-wide configuration file is given by envvar GITWEB_CONFIG_SYSTEM;\n> if it is not set, then by default /etc/gitweb.conf is used (one can\n> override the latter name via build-time configuration variable\n> GITWEB_CONFIG_SYSTEM). Note: sysconfdir is not taken into account\n> by gitweb/Makefile, but perhaps it should.\n> \n> Gitweb obtains configuration data from the following sources in the\n> following order:\n> \n> 1. gitweb's installation configuration file ($GITWEBDIR/gitweb_conf.perl)\n> 2. system-wide configuration file (/etc/gitweb.conf)\n> \n> First existing config file is used.\n\nLet me see if I understand this correctly: If there is an instance-local\nconfiguration file ($GITWEBDIR/gitweb_conf.perl by default) we outright\nignore all settings in the system-wide (/etc/gitweb.conf) configuration\nfile? That would mean that the system-wide configuration file isn't\nreally a system-wide set of defaults--to be built upon by a local\nconfiguration--at all, but is something much more akin to /etc/skel;\nused in total or completely overridden.\n\nComing from the perspective of an administrator of a fair amount of web\nhosting space I'd actually prefer that it be settable that both the\nsystem-wide configuration and the local one affect operation. This would\nallow for local setting of things such as adding a stylesheet while\nensuring consistency otherwise. The order of evaluation of configuration\nsettings sets would be \"built-in, system, local\" in that case (provided\nall exist). I can provide a patch to gitweb.perl for that if there is\ninterest.\n\n> Sidenote: we could replace GITWEB_CONFIG and GITWEB_CONFIG_SYSTEM in \n> gitweb.conf.txt during building documentation.\n\nI wasn't sure yet if I wanted to do @@thingy@@ substitution or not. (I'm\nstill not...)\n\n> > > +\n> > > +The syntax of the configuration files is that of PERL, as these files are\n> > > +indeed handled as fragments of PERL code (the language that gitweb itself is\n> > > +written in). Variables may be set using \"'our $variable = value'\"; text from\n> > > +\"#\" character until the end of a line is ignored. See the perlsyn(1) man page\n> > > +for more information.\n> \n> Actually using 'our $variable = ' is a safety check: if newer gitweb\n> does no longer use given value, using 'our' wouldn't cause errors.\n\nThat was boilerplate language taken pretty directly from the INSTALL and\nREADME files. If we change it here we should change it there as well (if\nit remains once we're done).\n\n> > The perl manual spells the name of that language as \"Perl\". \n\nI've seen it spelled all sorts of ugly ways, but if that's what they're\nusing I can too. ;-)\n\n> I think\n> > it might make sense to mention the syntax earlier, since it makes it\n> > less daunting to dive into the file right away.\n> \n> I think it might be good idea to provide bare-bones example here.\n> \n> > > +\n> > > +One good reason to take advatage of the system-wide and local gitweb\n> > > +configuration files is that not all settings may be set up directly in the CGI\n> > > +itself. Optional features – defined using the '%features' variable\n> > > +– must be set in one of the two configuration files.\n> > \n> > I don't follow what this paragraph is saying. Is the idea something\n> > like this?\n> > \n> > \tThe default configuration with no configuration file at all\n> > \tmay work perfectly well for some installations. Still, a\n> > \tconfiguration file is useful for customizing or tweaking the\n> > \tbehavior of gitweb in many ways, and some optional features\n> > \twill not be present unless explicitly enabled using the\n> > \tconfigurable %features variable.\n> \n> I think the idea is that not all of configuration knobs can be tweaked\n> during \"compile\"-time. Some require setting from configuration file.\n\nYes, that would benefit from some rewording.\n\n> Note: we probably want to mention gitweb/config.mak or config.mak somewhere\n> as place to save build-time configuration, persistently.\n\nGiven your preference for keeping gitweb/INSTALL as intact as possible,\nshould that not go there?\n\n> > > +\n> > > +CONFIGURATION SETTINGS\n> > > +----------------------\n> > \n> > Configuration settings as opposed to non-configuration settings? :)\n> > \n> > Maybe something like\n> > \n> > \tVARIABLES\n> > \t---------\n> > \n> > would be clearer.\n> \n> Perhaps.\n\nBut variables to do what?\n\n> > > +Standard Options\n> > > +~~~~~~~~~~~~~~~~~\n> > > +The following are not typically set or overridden at build time:\n> [...]\n> > > +\n> > > +$GIT::\n> > > +\tCore git executable to use.\n> > \n> > Ah, what a variable to start with. Maybe this can be snuck later in\n> > the list somehow, so the reader can get to juicier bits first.\n> \n> This is set at build time, by default to $(bindir)/git\n\nI chose to leave that in due to the fact that we've had a few threads on\nthe list and other places on the Internet in recent memory where it was\nasked how to override that. Order is thus far as given in my source\nmaterials. If it is set at build time I can move it to the other\n(non-standard) list.\n\n> > > +$version::\n> > > +\tGitweb version, set automatically when creating gitweb.cgi from\n> > > +\tgitweb.perl. You might want to modify it if you are running modified\n> > > +\tgitweb.\n> > \n> > Why would I want to set this in the config file? Wouldn't my patch to\n> > gitweb.cgi modify $version?\n> \n> Well, for running gitweb.perl (not build!) from command line I use\n> \n> our $version = \"current\";\n> \n> But this is I think rare case.\n\nI would hope so. In any case, as we part gitweb out I suspect it will be\nuseful to mention somewhere that this is settable, as distribution\nmaintainers are apt to fuss with things (for starters). As far as I'm\nconcerned the README and INSTALL files are fair game for modification if\nthis could be made more clear in one of them.\n\n> > > +$projectroot::\n> > > +\tAbsolute filesystem path which will be prepended to project path;\n> > > +\tthe path to repository is `$projectroot/$project`. Set to\n> > > +\t`$GITWEB_PROJECTROOT` during installation. This variable has to be\n> > > +\tset correctly for gitweb to find repositories.\n> > \n> > This is an interesting one. The description is not so clear to me ---\n> > I guess the idea is that if $projectroot = \"/srv/git\" then\n> > \n> > http://path/to/gitweb/installation/?p=foo/bar.git\n> > \n> > will map to /srv/git/foo/bar.git on the filesystem (and likewise for\n> > PATH_INFO based URLs)?\n> \n> Yes.\n\nThis was the one which bit me hard enough to decide to take this task\non. I really didn't appreciate having my gitweb and gitolite\ninstallations which had been getting along so well suddenly refuse to\ntalk to each other.\n\n> > > +$projects_list::\n> > > +\tSource of projects list, either directory to scan, or text file\n> > > +\twith list of repositories (in the \"` SP\n> > > +\t`\" line format; actually there can be\n> > > +\tany sequence of whitespace in place of space (SP)). Set to\n> > > +\t`$GITWEB_LIST` during installation. If empty, `$projectroot` is used\n> > > +\tto scan for repositories.\n> > \n> > Maybe clearer to emphasize the kinds of values it takes first? That\n> > is:\n> > \n> > \tSpace-separated list of paths to files listing projects or\n> > \tdirectories to be scanned for projects. Project list files\n> > \tshould list one project per line, with each line having the\n> > \tformat \"` SP\n> > \t`. The default is determined\n> > \tby the GITWEB_LIST makefile variable at installation time.\n> > \tIf this variable is empty, gitweb will fall back to scanning\n> > \tthe `$projectroot` for repositories.\n> \n> I think to not have long wall of text here, we should reference part\n> of documentation that explains how gitweb finds repositories, including\n> format of $projects_list file.\n\nPerhaps this longer explanation is fodder for gitweb.txt?\n\n> > [...]\n> > > +Configuration Options Often Set at Compile Time\n> > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > > +These configuration variables are often specified at compile time and are\n> > > +defined by default in the gitweb CGI itself:\n> > > +\n> > > +GIT_BINDIR::\n> > > +\tPoints where to find the git executable. You should set it up to\n> > > +\tthe place where the git binary was installed (usually /usr/bin) if you\n> > > +\tdon't install git from sources together with gitweb. [Default: $(bindir)]\n> > \n> > I don't think there is a GIT_BINDIR configuration variable, though\n> > there is a makefile variable with that name used to determine the\n> > default value of $GIT.\n\nOk, upon checking that is indeed \"compiled out\" during the build\nprocess.\n\n> > Likewise for the others. I don't think they belong in the manpage.\n> \n> I agree. What is important during build time \"only\" should remain in\n> gitweb/INSTALL.\n\nWe need to define what that is then, as some of these \"build time only\"\nlisted values are indeed settable items (granted, once the case is set\nproperly and a dollar sign is prefixed) such as $site_name,\n$site_header, and $site_footer. \n\nRemember, many people install from packages and not from source. If we\nmake them second-class citizens we only make our lives more difficult.\n\nIn any case, as I noted earlier, thus far I've been mostly just pulling\nstuff in from other places. It is now time to start cleaning it up.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"167750","messageId":"4DCC17BE.7000005@kernel.org","threadId":"27326","inReplyTo":"201105121701.26547.jnareb@gmail.com","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"J.H.","fromEmail":"warthog9@kernel.org","sentAt":"2011-05-12T17:24:14Z","receivedAt":"2011-05-12T17:24:14Z","isPatch":true,"sender":{"key":"warthog9@kernel.org","avatar":"https://avatars.githubusercontent.com/u/2334704?v=4"},"body":"On 05/12/2011 08:01 AM, Jakub Narebski wrote:\n> On Thu, 12 May 2011, Jonathan Nieder wrote:\n>> Drew Northup wrote:\n>>\n>>> This is a work in progress. Much of what is in it has been pulled\n>>> directly from the README and INSTALL files of gitweb. No effort has yet\n>>> been made to de-duplicate any of this.\n> \n> While it might be a good idea to split main part of gitweb/README into\n> gitweb.conf.txt (documenting configuration), and perhaps also separate\n> gitweb.txt (main page for gitweb, like SVN::Web manpage), I don't think\n> that much of gitweb/INSTALL should be moved.\n\nI would agree with this, if you are shooting for a config file\nman/txt/html page INSTALL has nothing to do with it, and serves a\ndifferent purpose.\n\n>>> TODO:\n>>> * Clean up README and INSTALL files\n>>> * Add Makefile rules to build man / HTML pages.\n>>> * Remove or rephrase redundant portions of original documentation\n>>> * A lot more...\n>>\n>> I agree with this TODO list. :) It should be possible to reuse rules from\n>> Documentation/Makefile if you put this under Documentation/. gitweb already\n>> keeps its tests under t/ for convenience; I think it's okay if it\n>> puts some documentation under Documentation/.\n> \n> Note that git-gui and gitk both also keep their manpages in Documentation/\n> as Documentation/git-gui.txt and Documentation/gitk.txt\n> \n> We can add \"doc\" target to gitweb/Makefile, which would delegate work to\n> ../Documentation/Makefile, similarly to existing \"test\" target in\n> gitweb/Makefile.\n\nI disagree slightly, I'd personally rather try and keep gitweb more\nself-contained under gitweb/. I can see the advantage of keeping the\ndocs under Documentation/ but I can also appreciate keeping gitweb self\ncontained, like it is currently.\n\n>>> +\n>>> +SYNOPSIS\n>>> +--------\n>>> +/etc/gitweb.conf\n> \n> I'd say\n> \n> +SYNOPSIS\n> +--------\n> +gitweb_conf.perl\n> +/etc/gitweb.conf\n> \n> or\n> \n> +SYNOPSIS\n> +--------\n> +$GITWEBDIR/gitweb_conf.perl\n> +/etc/gitweb.conf\n\nI'd prefer the later, I don't know of many people who actually use\n/etc/gitweb.conf, and I'd rather see this be a more generic man page\nthan steering someone who's implementing this to only trying to use\n/etc/gitweb.conf\n\n>> gitweb will also look for gitweb_config.perl along @INC, and\n>> the $GITWEB_CONFIG and $GITWEB_CONFIG_SYSTEM envvars can override\n>> these paths.\n> \n> I think that we don't need to describe envvars in synopsis, but we\n> should have per-gitweb configuration file (gitweb_conf.perl) in\n> \"Synopsis\" section.\n\nThat sounds more like an INSTALL thing.\n\n[...]\n\nBeyond that I've no real issue that haven't already been brought up, but\nI do want to make sure that the ultimate plan here is to add the scripts\nthat generate this vs. the final output, right? I mean we already have\n2 places this documentation lives (in gitweb.perl and README), I'm not\nsure we need a 3rd place to update the documentation at by hand. Just\nasking.\n\n- John 'Warthog9' Hawley\n"},{"id":"167752","messageId":"201105122008.53322.jnareb@gmail.com","threadId":"27326","inReplyTo":"1305141664.30104.11.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-12T18:08:51Z","receivedAt":"2011-05-12T18:08:51Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 11 May 2011, Drew Northup wrote:\n\n> This is a work in progress. Much of what is in it has been pulled\n> directly from the README and INSTALL files of gitweb. No effort has yet\n> been made to de-duplicate any of this.\n> \n> TODO:\n\nI would add here:\n\n * Move most of gitweb's README and INSTALL into gitweb.txt and\n gitweb.conf.txt, so that their documentation can be easily viewed.\n\n> * Clean up README and INSTALL files\n\nThis is connected to added point.\n\n> * Add Makefile rules to build man / HTML pages.\n\nNote that if we decode to go Documentation/gitweb{,.conf}.txt route, i.e.\nputting docs in Documentation, this point would change to the following:\n\n * Include gitweb's docs in 'gitweb' package (git.spec.in).\n\ndiff --git i/git.spec.in w/git.spec.in\nindex 91c8462..06b27eb 100644\n--- i/git.spec.in\n+++ w/git.spec.in\n@@ -200,6 +200,9 @@ rm -rf $RPM_BUILD_ROOT\n %files -n gitweb\n %defattr(-,root,root)\n %{_datadir}/gitweb\n+%{!?_without_docs: %{_mandir}/man1/*gitweb*.1*}\n+%{!?_without_docs: %{_mandir}/man5/*gitweb*.5*}\n+%{!?_without_docs: %doc Documentation/*gitweb*.html }\n \n %files -n perl-Git -f perl-files\n %defattr(-,root,root)\n\n\n[...]\n> If you don't really need (or want) to be on the CC list let me know. You were\n> in the output of 'git blame'....\n\nI have culled CC list a bit, please notify if you want to be \nexcluded/included.\n\n[Skipping issues mentioned in other subthread]\n \n> +DISCUSSION\n> +----------\n> +\n> +The location of `gitweb.conf` is defined at compile time using the\n> +configuration value `GITWEB_CONFIG_SYSTEM` and defaults to /etc/gitweb.conf.\n> +The name of the per-instance configuration file is defined in gitweb by\n> +`GITWEB_CONFIG`.\n\n ...and defaults to gitweb_conf.perl.\n\n> +\n> +*NOTE:* Values defined in the per-instance configuration file override both\n> +values found in the gitweb CGI as well as values found in the system-wide\n> +gitweb.conf file.\n\nActually if there is per-instance configuration file, it is used, and only\notherwise system-wide configuration file is sourced. But probably that\nshould be changed:\n\ndiff --git i/gitweb/gitweb.perl w/gitweb/gitweb.perl\nindex acdc5b8..9527cd2 100755\n--- i/gitweb/gitweb.perl\n+++ w/gitweb/gitweb.perl\n@@ -637,12 +637,13 @@ sub evaluate_gitweb_config {\n \tour $GITWEB_CONFIG = $ENV{'GITWEB_CONFIG'} || \"++GITWEB_CONFIG++\";\n \tour $GITWEB_CONFIG_SYSTEM = $ENV{'GITWEB_CONFIG_SYSTEM'} || \"++GITWEB_CONFIG_SYSTEM++\";\n \t# die if there are errors parsing config file\n+\tif (-e $GITWEB_CONFIG_SYSTEM) {\n+\t\tdo $GITWEB_CONFIG_SYSTEM;\n+\t\tdie $@ if $@;\n+\t}\n \tif (-e $GITWEB_CONFIG) {\n \t\tdo $GITWEB_CONFIG;\n \t\tdie $@ if $@;\n-\t} elsif (-e $GITWEB_CONFIG_SYSTEM) {\n-\t\tdo $GITWEB_CONFIG_SYSTEM;\n-\t\tdie $@ if $@;\n \t}\n }\n \n\nNote: if we change it, we should mention priority of config sources, like\ne.g. in ssh_conf(5).\n\nValues in config file override default values found in gitweb sources.\n\n> +\n> +The syntax of the configuration files is that of PERL, as these files are\n> +indeed handled as fragments of PERL code (the language that gitweb itself is\n> +written in). Variables may be set using \"'our $variable = value'\"; text from\n> +\"#\" character until the end of a line is ignored.\n\nI think it would be nice to have an example here, something like:\n\n-----\nour $site_name = 'My Gitweb'; # or 'localhost'\n-----\n\n> See the perlsyn(1) man page \n> +for more information.\n\nIs this how other manpages should be referenced in AsciiDoc?\n\n\nBTW. What is –, and could we write it using something more readable?\n\n> +One good reason to take advantage of the system-wide and local gitweb\n> +configuration files is that not all settings may be set up directly in the CGI\n> +itself. Optional features – defined using the '%features' variable\n> +– must be set in one of the two configuration files.\n> +\n> +CONFIGURATION SETTINGS\n> +----------------------\n> +Standard Options\n> +~~~~~~~~~~~~~~~~~\n> +The following are not typically set or overridden at build time:\n\nHmmm... There are four kinds of configuration variables:\n\n1. Variables with default values set during build time\n\n 1.a. Those that usually do not need to be overridden, even if you are\n using packaged gitweb, and do not compile it yourself, like\n e.g. $GIT or $gitweb_js.\n\n 1.b. Those that usually need to be overridden when we cannot control\n build-time configuration, e.g. using gitweb package, like e.g.\n $projectroot.\n\n If we build gitweb from sources, we can use config.mak or\n gitweb/config.mak to save build time configuration.\n\n\n2. Variables which cannot be configured during build time\n\n 2.a. Those that gitweb sets automatically, and usually do not need to\n be changed, like e.g. $base_url.\n\n 2.b. Those that need to be set in config file to make use of feature.\n This includes whole %feature-based configuration.\n\n\nHere there is a table:\n\n Variable | type | build value\n ======================================================================\n $GIT | 1.a | \"$(bindir)/git\" e.g. \"/usr/bin/git\"\n $version | 1.a | \"$(GIT_VERSION)\" e.g. \"1.7.5\"\n $projectroot | 1.b !!| \"/pub/git\"\n $projects_list | 1.[ab]| \"\", which means $projectroot\n $my_url, $my_uri | 2.a |\n $base_url | 2.a |\n $home_link | 2.a |\n @stylesheets | 1.a | \"static/gitweb.css\"\n $logo_url | 2.a ? | \"http://git-scm.com/\"\n $logo_label | 2.a ? | \"git homepage\"\n $projects_list_description_width\n | 2.b | 25\n @git_base_url_list | 1.b | \"\", which means no git base url\n $default_blob_plain_mimetype\n | 2.a | \"text/plain\"\n $default_text_plain_charset\n | 2.b ? | undef\n $mimetypes_file | 2.b | undef\n $fallback_encoding | 2.b | \"latin1\"\n @diff_opts | 2.b | ('-M')\n $prevent_xss | 2.b | 0, which means false\n $maxload | 2.b | 300\n $highlight_bin | 1.[ab]| \"highlight\"\n $per_request_config |2.b | 1\n .........................................................................\n $project_maxdepth | 1.a | 2007\n $home_link_str | 1.a ? | \"projects\"\n $site_name |[12].a?| ($ENV{'SERVER_NAME'} || \"Untitled\") . \" Git\"\n $site_header, $site_footer \n | 1.b | \"\"\n $home_text | 1.b | \"indextext.html\"\n $logo | 1.a ? | \"static/git-logo.png\"\n $favicon | 1.a ? | \"static/git-favicon.png\"\n $javascript | 1.a! | \"static/gitweb.js\"\n $default_projects_order\n | 2.a | \"project\"\n $export_ok | 1.b | \"\", which means feature is turned off\n $export_auth_hook | 2.b | undef, which means feature is turned off\n $strict_export | 1.b | \"\", which means feature is turned off\n\n> +Configuration Options Often Set at Compile Time\n> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +These configuration variables are often specified at compile time and are\n> +defined by default in the gitweb CGI itself:\n> +\n> +GIT_BINDIR::\n> +\tPoints where to find the git executable. You should set it up to\n> +\tthe place where the git binary was installed (usually /usr/bin) if you\n> +\tdon't install git from sources together with gitweb. [Default: $(bindir)]\n[...]\n\nI think this should be left in gitweb/INSTALL, as those are important\n_only_ during building gitweb.\n\n> +Configuration File Example\n> +~~~~~~~~~~~~~~~~~~~~~~~~~~\n> +\n> +To enable blame, pickaxe search, and snapshot support, while allowing\n> +individual projects to turn them off, put the following in your\n> +GITWEB_CONFIG file:\n> +\n> + $feature{'blame'}{'default'} = [1];\n> + $feature{'blame'}{'override'} = 1;\n\nI think this example requires explaining upfront what does it mean to\nallow feature override, i.e. about per-repository configuration.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"167753","messageId":"1305224164.24667.87.camel@drew-northup.unet.maine.edu","threadId":"27326","inReplyTo":"4DCC17BE.7000005@kernel.org","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-05-12T18:16:04Z","receivedAt":"2011-05-12T18:16:04Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"On Thu, 2011-05-12 at 10:24 -0700, J.H. wrote:\n> On 05/12/2011 08:01 AM, Jakub Narebski wrote:\n> > On Thu, 12 May 2011, Jonathan Nieder wrote:\n> >> Drew Northup wrote:\n> >>\n> >>> This is a work in progress. Much of what is in it has been pulled\n> >>> directly from the README and INSTALL files of gitweb. No effort has yet\n> >>> been made to de-duplicate any of this.\n> > \n> > I don't think\n> > that much of gitweb/INSTALL should be moved.\n> \n> I would agree with this, if you are shooting for a config file\n> man/txt/html page INSTALL has nothing to do with it, and serves a\n> different purpose.\n\nAs noted earlier, we need to make sure that nothing that should be\ndocumented as (reasonably) settable during runtime remains in the\nINSTALL file if that is to be the case. We aren't there yet.\n\n> >>> TODO:\n> >>> * Clean up README and INSTALL files\n> >>> * Add Makefile rules to build man / HTML pages.\n> >>> * Remove or rephrase redundant portions of original documentation\n...\n> \n> Beyond that I've no real issue that haven't already been brought up, but\n> I do want to make sure that the ultimate plan here is to add the scripts\n> that generate this vs. the final output, right? I mean we already have\n> 2 places this documentation lives (in gitweb.perl and README), I'm not\n> sure we need a 3rd place to update the documentation at by hand. Just\n> asking.\n\nI don't think that in the long term it makes sense to leave the README\nas it is if we are extracting stuff into other files. As for removing\ndocumentation lines from the \"executable\" itself, I'm not going there.\n(I almost never recommend removing documentation from a program's source\ntext, even when it is excessive.)\n\nThis was a FIRST DRAFT. Fun stuff like make scripting and such can start\nshortly if we continue to think splitting this out into asciidoc is a\ngood idea. (It is sounding like it.) I honestly wasn't planning on a\nformal v1 without completing (or nearly so) the TODO list above--hence\nthe lack of a sign-off line.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"167754","messageId":"201105122017.52373.jnareb@gmail.com","threadId":"27326","inReplyTo":"4DCC17BE.7000005@kernel.org","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-12T18:17:51Z","receivedAt":"2011-05-12T18:17:51Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 12 May 2011, J.H. wrote:\n\n> Beyond that I've no real issue that haven't already been brought up, but\n> I do want to make sure that the ultimate plan here is to add the scripts\n> that generate this vs. the final output, right? I mean we already have\n> 2 places this documentation lives (in gitweb.perl and README), I'm not\n> sure we need a 3rd place to update the documentation at by hand. Just\n> asking.\n\nI think the ultimate goal is to move _documentation_ out of gitweb/README\n(and some from gitweb/INSTALL) to gitweb.txt (or gitweb.pod) and\ngitweb.conf.txt manpages... so that gitweb/README would be of size of\nother README's (with sole exception of t/README, which is special case),\ni.e. up to around 2,300 lines, and not 23,000 lines (10 times more).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"167755","messageId":"1305225191.24667.101.camel@drew-northup.unet.maine.edu","threadId":"27326","inReplyTo":"201105122008.53322.jnareb@gmail.com","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-05-12T18:33:11Z","receivedAt":"2011-05-12T18:33:11Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Thu, 2011-05-12 at 20:08 +0200, Jakub Narebski wrote:\n> On Wed, 11 May 2011, Drew Northup wrote:\n\n> > +\n> > +The syntax of the configuration files is that of PERL, as these files are\n> > +indeed handled as fragments of PERL code (the language that gitweb itself is\n> > +written in). Variables may be set using \"'our $variable = value'\"; text from\n> > +\"#\" character until the end of a line is ignored.\n> \n> I think it would be nice to have an example here, something like:\n> \n> -----\n> our $site_name = 'My Gitweb'; # or 'localhost'\n> -----\n\nLooks reasonable to me...\n\n> > See the perlsyn(1) man page \n> > +for more information.\n> \n> Is this how other manpages should be referenced in AsciiDoc?\n> \n> \n> BTW. What is –, and could we write it using something more readable?\n\nThat's an en dash. A lot of people write it \"blah - blah,\" but that's\nnot typographically correct (and asciidoc isn't nice enough to fix it\nfor us, as that would likely mess something else up). It compiles\nproperly into both HTML and manpages. I didn't think that dropping the\nUTF-8 character into the asciidoc sources would go over well.\n\n> > +One good reason to take advantage of the system-wide and local gitweb\n> > +configuration files is that not all settings may be set up directly in the CGI\n> > +itself. Optional features – defined using the '%features' variable\n> > +– must be set in one of the two configuration files.\n> > +\n> > +CONFIGURATION SETTINGS\n> > +----------------------\n> > +Standard Options\n> > +~~~~~~~~~~~~~~~~~\n> > +The following are not typically set or overridden at build time:\n> \n> Hmmm... There are four kinds of configuration variables:\n\nThank you for this extraction & table.\n\n> > +Configuration Options Often Set at Compile Time\n> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > +These configuration variables are often specified at compile time and are\n> > +defined by default in the gitweb CGI itself:\n> > +\n> > +GIT_BINDIR::\n> > +\tPoints where to find the git executable. You should set it up to\n> > +\tthe place where the git binary was installed (usually /usr/bin) if you\n> > +\tdon't install git from sources together with gitweb. [Default: $(bindir)]\n> [...]\n> \n> I think this should be left in gitweb/INSTALL, as those are important\n> _only_ during building gitweb.\n\nUnderstood, I'll have to audit the list for values like that. \n\n> > +Configuration File Example\n> > +~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > +\n> > +To enable blame, pickaxe search, and snapshot support, while allowing\n> > +individual projects to turn them off, put the following in your\n> > +GITWEB_CONFIG file:\n> > +\n> > + $feature{'blame'}{'default'} = [1];\n> > + $feature{'blame'}{'override'} = 1;\n> \n> I think this example requires explaining upfront what does it mean to\n> allow feature override, i.e. about per-repository configuration.\n\nAgreed, I was just pulling thing together in this step. I think that\nthere are likely other worthy additions to this portion.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"167757","messageId":"201105122101.54710.jnareb@gmail.com","threadId":"27326","inReplyTo":"1305225191.24667.101.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH/WIP] Starting work on a man page for /etc/gitweb.conf","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-12T19:01:53Z","receivedAt":"2011-05-12T19:01:53Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 12 May 2011, Drew Northup wrote:\n> On Thu, 2011-05-12 at 20:08 +0200, Jakub Narebski wrote:\n>> On Wed, 11 May 2011, Drew Northup wrote:\n> \n>>> +\n>>> +The syntax of the configuration files is that of PERL, as these files are\n>>> +indeed handled as fragments of PERL code (the language that gitweb itself is\n>>> +written in). Variables may be set using \"'our $variable = value'\"; text from\n>>> +\"#\" character until the end of a line is ignored.\n>> \n>> I think it would be nice to have an example here, something like:\n>> \n>> -----\n>> our $site_name = 'My Gitweb'; # or 'localhost'\n>> -----\n> \n> Looks reasonable to me...\n\nWell, this is very much off the cuff example; I hope for a better example,\nthough it doesn't matter much here...\n\n>>> See the perlsyn(1) man page \n>>> +for more information.\n>> \n>> Is this how other manpages should be referenced in AsciiDoc?\n\nShouldn't we use some 'link:perlsyn[1]' or something like that here?\n\n>> \n>> BTW. What is –, and could we write it using something more readable?\n> \n> That's an en dash. A lot of people write it \"blah - blah,\" but that's\n> not typographically correct (and asciidoc isn't nice enough to fix it\n> for us, as that would likely mess something else up). It compiles\n> properly into both HTML and manpages. I didn't think that dropping the\n> UTF-8 character into the asciidoc sources would go over well.\n\nDoesn't AsciiDoc convert '--' to en-dash? If not, perhaps adding \nappropriate definition to Documentation/asciidoc.conf and using \"{endash}\"\ninstead of \"–\" would be a better solution.\n\n>>> +CONFIGURATION SETTINGS\n>>> +----------------------\n>>> +Standard Options\n>>> +~~~~~~~~~~~~~~~~~\n>>> +The following are not typically set or overridden at build time:\n>> \n>> Hmmm... There are four kinds of configuration variables:\n> \n> Thank you for this extraction & table.\n\nNote that some of those variables (those below \".....\") are not present\nin gitweb/README and are not present in your patch.\n \n>>> +Configuration Options Often Set at Compile Time\n>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n>>> +These configuration variables are often specified at compile time and are\n>>> +defined by default in the gitweb CGI itself:\n>>> +\n>>> +GIT_BINDIR::\n>>> +\tPoints where to find the git executable. You should set it up to\n>>> +\tthe place where the git binary was installed (usually /usr/bin) if you\n>>> +\tdon't install git from sources together with gitweb. [Default: $(bindir)]\n>> [...]\n>> \n>> I think this should be left in gitweb/INSTALL, as those are important\n>> _only_ during building gitweb.\n> \n> Understood, I'll have to audit the list for values like that. \n\nI meant here the whole (sub)section.\n\n>>> +Configuration File Example\n>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~\n>>> +\n>>> +To enable blame, pickaxe search, and snapshot support, while allowing\n>>> +individual projects to turn them off, put the following in your\n>>> +GITWEB_CONFIG file:\n>>> +\n>>> + $feature{'blame'}{'default'} = [1];\n>>> + $feature{'blame'}{'override'} = 1;\n>> \n>> I think this example requires explaining upfront what does it mean to\n>> allow feature override, i.e. about per-repository configuration.\n> \n> Agreed, I was just pulling thing together in this step. I think that\n> there are likely other worthy additions to this portion.\n\nRight, we need some documentation about %feature, like e.g. what does\noverriding means, and why 'default' needs to be array (currently).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"167884","messageId":"201105151234.29598.jnareb@gmail.com","threadId":"27326","inReplyTo":"1305141664.30104.11.camel@drew-northup.unet.maine.edu","subject":"[RFC/PATCH] gitweb: Starting work on a man page for gitweb (WIP)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-15T10:34:28Z","receivedAt":"2011-05-15T10:34:28Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Gitweb documentation currently consist of gitweb/README, gitweb/INSTALL\nand comments in gitweb source code. This is harder to find, use and\nbrowse that manpages (\"man gitweb\" or \"git help gitweb\") and HTML\ndocumentation (\"git help --web gitweb\").\n\nThe goal is to move documentation out of gitweb/README to gitweb.txt and\ngitweb.conf.txt manpages, reducing its size 10x from around 500 to\naround 50 lines (two pages), and move information not related drectly to\nbuilding and installing gitweb out of gitweb/INSTALL there.\n\nTo build gitweb documentation you can use\n\n make -C gitweb doc\n\nor\n\n cd gitweb; make doc\n\n\nThis is a work in progress. Much of what is in it has been pulled\ndirectly from the README and INSTALL files of gitweb. No effort has\nyet been made to de-duplicate any of this, i.e. to remove contents\nfrom gitweb/README and gitweb/INSTALL. The AsciiDoc might (and\nprobably does) contain formatting errors.\n\nCurrent version is almost direct translation of SVN::Web manpage, and\nis missing much of information that finally are to be moved from\ngitweb/README to here.\n\nInspired-by: Drew Northup \nSigned-off-by: Jakub Narebski \n---\nThis is intended to go hand in hand with Drew's gitweb.conf.txt (which\nprobably should also go to Documentation).\n\nThe gitweb/Makefile change is here simply to be able to use \"make doc\"\nfrom 'gitweb' directory, and have it work. It would probably be more\nin line what Documentation/Makefile does.\n\nTODO:\n * Expand gitweb.txt beyond being simple translation of SVN::Web.3pm\n http://p3rl.org/SVN::Web\n * Fix and improve AsciiDoc formatting\n * Clean up gitweb/README and gitweb/INSTALL files\n * Make doc-related part of gitweb/Makefile more robust\n * Remove or rephrase redundant portions of original documentation\n * A lot more...\n\n Documentation/Makefile | 2 +-\n Documentation/gitweb.txt | 216 ++++++++++++++++++++++++++++++++++++++++++++++\n git.spec.in | 3 +\n gitweb/Makefile | 7 ++\n 4 files changed, 227 insertions(+), 1 deletions(-)\n create mode 100644 Documentation/gitweb.txt\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 36989b7..958c20a 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -1,7 +1,7 @@\n MAN1_TXT= \\\n \t$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \\\n \t\t$(wildcard git-*.txt)) \\\n-\tgitk.txt git.txt\n+\tgitk.txt gitweb.txt git.txt\n MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \\\n \tgitrepository-layout.txt\n MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \\\ndiff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt\nnew file mode 100644\nindex 0000000..78cee1a\n--- /dev/null\n+++ b/Documentation/gitweb.txt\n@@ -0,0 +1,216 @@\n+gitweb(1)\n+=========\n+\n+NAME\n+----\n+gitweb - Git web interface (web frontend to Git repositories)\n+\n+SYNOPSIS\n+--------\n+To get started with gitweb, run linkgit:git-instaweb[1] from a git repository.\n+This would configure and start your web server and run web browser pointing to\n+gitweb page.\n+\n+See http://git.kernel.org/?p=git/git.git;a=tree;f=gitweb or\n+http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/ for gitweb source code, browsed\n+using gitweb.\n+\n+\n+DESCRIPTION\n+-----------\n+Gitweb provides a web interface to git repositories. It's features include:\n+\n+* Viewing multiple Git repositories with common root.\n+* Browsing every revision of the repository.\n+* Viewing the contents of files in the repository at any revision.\n+* Viewing the revision log of branches, history of files and directories,\n+ see what was changed when, by who.\n+* Viewing the blame/annotation details of any file (if enabled).\n+* Generating RSS and Atom feeds of commits, for any branch.\n+ The feeds are auto-discoverable in modern web browsers.\n+* Viewing everything that was changed in a revision, and step through\n+ revisions one at a time, viewing the history of the repository.\n+* Finding commits which commit messages matches given search term.\n+\n+CONFIGURATION\n+-------------\n+Various aspects of gitweb's behavior can be controlled through the configuration\n+file `gitweb_conf.perl` or `/etc/gitweb.conf`. See the linkgit:gitweb.conf[5]\n+for details.\n+\n+Repositories\n+~~~~~~~~~~~~\n+Gitweb can show information from one or more Git repositories. These\n+repositories have to be all on local filesystem, and have to share common\n+repository root, i.e. be all under a single parent repository.\n+\n+-----------------------------------------------------------------------\n+our $projectroot = '/path/to/parent/directory';\n+-----------------------------------------------------------------------\n+\n+...\n+\n+ACTIONS, AND URLS\n+-----------------\n+Gitweb can use path_info (component) based URLs, or it can pass all necessary\n+information via query parameters. The typical gitweb URLs are broken down in to\n+five components:\n+\n+-----------------------------------------------------------------------\n+.../gitweb.cgi///:/?\n+-----------------------------------------------------------------------\n+\n+repo::\n+\tThe repository the action will be performed on.\n++\n+\tAll actions except for those that list all available projects,\n+\tin whatever form, require this parameter.\n+\n+action::\n+\tThe action that will be run.\n+\n+revision::\n+\tRevision shown.\n+\n+path::\n+\tThe path within the that the action is performed on.\n+\n+arguments::\n+\tAny arguments that control the behaviour of the action.\n+\n+...\n+\n+Each action is implemented as a subroutine, and must be present in %actions\n+hash. Some actions are disabled by default, and must be turned on via feature\n+mechanism.\n+\n+The standard actions are:\n+\n+blame::\n+blame_incremental::\n+\tShows the blame (also called annotation) information for a file. On a\n+\tper line basis it shows the revision in which that line was last changed\n+\tand the user that committed the change.\n++\n+\tThis action is disabled by default for performance reasons.\n+\n+blob::\n+tree::\n+\tShows the files and directories in a given repository path, at given\n+\trevision. This is default command if no action is specified in the URL,\n+\tand path is given.\n+\n+blob_plain::\n+\tReturns the raw data for the file in given repository, at given path and\n+\trevision. Links to this action are marked 'raw'.\n+\n+blobdiff::\n+\tShows the difference between two revisions of the same file.\n+\n+project_list::\n+\tLists the available Git repositories. This is the default command if no\n+\trepository is specified in the URL.\n+\n+log::\n+shortlog::\n+\tShows log information (commit message or just commit subject) for a\n+\tgiven branch (starting from given revision).\n+\n+commit::\n+commitdiff::\n+\tShows information about a specific commit in a repository.\n+\n+rss::\n+atom::\n+\tGenerates an RSS (or Atom) feed of changes to repository.\n+\n+WEB SERVERS\n+-----------\n+This section explains how to configure some common webservers to run gitweb. In\n+all cases, `/path/to/gitweb` in the examples is the directory you ran installed\n+gitweb in, and contains `gitweb_config.perl`.\n+\n+If you've configured a web server that isn't listed here for gitweb, please send\n+in the instructions so they can be included in a future release.\n+\n+Apache as CGI\n+~~~~~~~~~~~~~\n+Apache must be configured to support CGI scripts in the directory in\n+which gitweb is installed. Let's assume that it is '/var/www/cgi-bin'\n+directory.\n+\n+-----------------------------------------------------------------------\n+ScriptAlias /cgi-bin/ \"/var/www/cgi-bin/\"\n+\n+\n+ Options Indexes FollowSymlinks ExecCGI\n+ AllowOverride None\n+ Order allow,deny\n+ Allow from all\n+\n+-----------------------------------------------------------------------\n+\n+With that configuration the full path to browse repositories would be:\n+\n+ http://server/cgi-bin/gitweb.cgi\n+\n+Apache with mod_perl, via ModPerl::Registry\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+You can use mod_perl with gitweb. You must install Apache::Registry\n+(for mod_perl 1.x) or ModPerl::Registry (for mod_perl 2.x) to enable\n+this support.\n+\n+Assuming that gitweb is installed to '/var/www/perl', the following\n+Apache configuration is suitable.\n+\n+-----------------------------------------------------------------------\n+Alias /perl \"/var/www/perl\"\n+\n+\n+ SetHandler perl-script\n+ PerlResponseHandler ModPerl::Registry\n+ PerlOptions +ParseHeaders\n+ Options Indexes FollowSymlinks +ExecCGI\n+ AllowOverride None\n+ Order allow,deny\n+ Allow from all\n+\n+-----------------------------------------------------------------------\n+\n+With that configuration the full path to browse repositories would be:\n+\n+ http://server/perl/gitweb.cgi\n+\n+Apache with FastCGI\n+~~~~~~~~~~~~~~~~~~~\n+Gitweb works with Apache and FastCGI. First you need to rename, copy\n+or symlink gitweb.cgi to gitweb.fcgi. Let's assume that gitweb is\n+installed in '/usr/share/gitweb' directory. The following Apache\n+configuration is suitable (UNTESTED!)\n+\n+-----------------------------------------------------------------------\n+FastCgiServer /usr/share/gitweb/gitweb.cgi\n+ScriptAlias /gitweb /usr/share/gitweb/gitweb.cgi\n+\n+Alias /gitweb/static /usr/share/gitweb/static\n+\n+ SetHandler default-handler\n+\n+-----------------------------------------------------------------------\n+\n+With that configuration the full path to browse repositories would be:\n+\n+ http://server/gitweb\n+\n+BUGS\n+----\n+Please report any bugs or feature requests to git@vger.kernel.org,\n+putting \"gitweb\" somewhere in the subject of email.\n+\n+SEE ALSO\n+--------\n+linkgit:gitweb.conf[5], linkgit:git-instaweb[1]\n+\n+GIT\n+---\n+Part of the linkgit:git[1] suite\ndiff --git a/git.spec.in b/git.spec.in\nindex 91c8462..06b27eb 100644\n--- a/git.spec.in\n+++ b/git.spec.in\n@@ -200,6 +200,9 @@ rm -rf $RPM_BUILD_ROOT\n %files -n gitweb\n %defattr(-,root,root)\n %{_datadir}/gitweb\n+%{!?_without_docs: %{_mandir}/man1/*gitweb*.1*}\n+%{!?_without_docs: %{_mandir}/man5/*gitweb*.5*}\n+%{!?_without_docs: %doc Documentation/*gitweb*.html }\n \n %files -n perl-Git -f perl-files\n %defattr(-,root,root)\ndiff --git a/gitweb/Makefile b/gitweb/Makefile\nindex 0a6ac00..945251e 100644\n--- a/gitweb/Makefile\n+++ b/gitweb/Makefile\n@@ -112,6 +112,8 @@ endif\n \n GITWEB_FILES += static/git-logo.png static/git-favicon.png\n \n+GITWEB_DOC = gitweb.1 gitweb.html\n+\n GITWEB_REPLACE = \\\n \t-e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \\\n \t-e 's|++GIT_BINDIR++|$(bindir)|g' \\\n@@ -155,6 +157,11 @@ test-installed:\n \tGITWEB_TEST_INSTALLED='$(DESTDIR_SQ)$(gitwebdir_SQ)' \\\n \t\t$(MAKE) -C ../t gitweb-test\n \n+### Documentation\n+\n+doc:\n+\t$(MAKE) -C ../Documentation $(GITWEB_DOC)\n+\n ### Installation rules\n \n install: all\n-- \n1.7.5\n"}]}