delta/git.git/gitweb/README, branch jk/string-list-static-init

gitweb/README: remove reference to git.kernel.org

2013-03-07T19:38:33+00:00

git.kernel.org no longer uses gitweb but has switched to cgit.

Info about this can be found on: https://www.kernel.org/pelican.html
or simply by looking at http://git.kernel.org . This is change since
2013-03-01.

Signed-off-by: Fredrik Gustafsson 
Signed-off-by: Junio C Hamano

gitweb: Add gitweb(1) manpage for gitweb itself

2011-10-16T18:09:34+00:00

Most of what is in gitweb.txt it has been pulled directly from the
README and INSTALL files of gitweb.

Current version is somewhat based on structure of SVN::Web manpage
(one of web interfaces for Subversion).

gitweb.conf(5) i.e. gitweb configuration manpage now refers to
appropriate sections in gitweb(1).  gitweb/README now refers to
gitweb/INSTALL and gitweb(1) manpage.  gitweb/INSTALL now refers to
gitweb.conf(5) and gitweb(1).

Inspired-by: Drew Northup 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Add gitweb.conf(5) manpage for gitweb configuration files

2011-10-16T18:09:34+00:00

Much of what is in gitweb.conf.txt has been pulled directly from the
README file of gitweb.  The manpage was supplemented with description
of missing gitweb config variables, and with description of gitweb's
%features.

There remains a bit of redundancy, which should be reduced if
possible... but I think some of duplication of information is
inevitable.

[jn: Improved, extended, removed duplicate info from README]

Signed-off-by: Drew Northup 
Signed-off-by: Jakub Narebski 
Helped-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

gitweb: Introduce common system-wide settings for convenience

2011-07-24T23:22:21+00:00

Because of backward compatibility we cannot change gitweb to always
use /etc/gitweb.conf (i.e. even if gitweb_config.perl exists).  For
common system-wide settings we therefore need separate configuration
file: /etc/gitweb-common.conf.

Long description:

gitweb currently obtains configuration from the following sources:

  1. per-instance configuration file (default: gitweb_conf.perl)
  2. system-wide configuration file (default: /etc/gitweb.conf)

If per-instance configuration file exists, then system-wide
configuration is _not used at all_.  This is quite untypical and
suprising behavior.

Moreover it is different from way git itself treats /etc/git.conf.  It
reads in stuff from /etc/git.conf and then local repos can change or
override things as needed.  In fact this is quite beneficial, because
it gives site admins a simple and easy way to give an automatic hint
to a repo about things the admin would like.

On the other hand changing current behavior may lead to the situation,
where something in /etc/gitweb.conf may interfere with unintended
interaction in the local repository.  One solution would be to
_require_ to do explicit include; with read_config_file() it is now
easy, as described in gitweb/README (description introduced in this
commit).

But as J.H. noticed we cannot ask people to modify their per-instance
gitweb config file to include system-wide settings, nor we can require
them to do this.

Therefore, as proposed by Junio, for gitweb to have centralized config
elements while retaining backwards compatibility, introduce separate
common system-wide configuration file, by default /etc/gitweb-common.conf

Noticed-by: Drew Northup 
Helped-by: John 'Warthog9' Hawley 
Inspired-by: Junio C Hamano 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Move information about installation from README to INSTALL

2011-06-02T18:14:21+00:00

Almost straightformard moving of "How to configure gitweb for your
local system" section from gitweb/README to gitweb/INSTALL, as it is
about build time configuration.  Updated references to it.

Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: Optional grouping of projects by category

2011-04-29T21:21:48+00:00

This adds the $projects_list_group_categories option which, if enabled,
will result in grouping projects by category on the project list page.
The category is specified for each project by the $GIT_DIR/category file
or the 'gitweb.category' variable in its configuration file. By default,
projects are put in the $project_list_default_category category.

Note:
- Categories are always sorted alphabetically, with projects in
  each category sorted according to the globally selected $order.
- When displaying a subset of all the projects (page limiting), the
  category headers are only displayed for projects present on the page.

The feature is inspired from Sham Chukoury's patch for the XMMS2
gitweb, but has been rewritten for the current gitweb code. The CSS
for categories is inspired from Gustavo Sverzut Barbieri's patch to
group projects by path.

Thanks to Florian Ragwitz for Perl tips.

[jn: Updated to post restructuring projects list generation, fixed bugs,
 added very basic test in t9500 that there are no warnings from Perl.]

Signed-off-by: Sebastien Cevey 
Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

remove doubled words, e.g., s/to to/to/, and fix related typos

2011-04-13T18:59:11+00:00

I found that some doubled words had snuck back into projects from which
I'd already removed them, so now there's a "syntax-check" makefile rule in
gnulib to help prevent recurrence.

Running the command below spotted a few in git, too:

  git ls-files | xargs perl -0777 -n \
    -e 'while (/\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt])\s+\1\b/gims)' \
    -e '{$n=($` =~ tr/\n/\n/ + 1); ($v=$&)=~s/\n/\\n/g;' \
    -e 'print "$ARGV:$n:$v\n"}'

Signed-off-by: Jim Meyering 
Signed-off-by: Junio C Hamano

gitweb: document $per_request_config better

2010-11-30T01:14:52+00:00

Global variables $my_url, $my_uri and $base_url have subtle interactions
that need to be desribed, and can be influenced most cleanly by
$per_request_config.

Signed-off-by: Jonathan Nieder 
Acked-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

gitweb: selectable configurations that change with each request

2010-11-30T01:13:35+00:00

Allow selecting whether configuration file should be (re)parsed on each
request (the default, for backward compatibility with configurations that
change per session, see commit 7f425db (gitweb: allow configurations that
change with each request, 2010-07-30)), or whether should it be parsed only
once (for performance speedup for persistent environments, though currently
only FastCGI is able to make use of it, when flexibility is not important).

You can also have configuration file parsed only once, but have parts of
configuration (re)evaluated once per each request.

This is done by introducing $per_request_config variable: if set to code
reference, this code would be run once per request, while config file would
be parsed only once.  For example gitolite's contrib/gitweb/gitweb.conf
fragment mentioned in 7f425db could be rewritten as

  our $per_request_config = sub {
  	$ENV{GL_USER} = ($cgi && $cgi->remote_user) || "gitweb";
  };

to make use of this feature.

If $per_request_config is not a code reference, it is taken to be boolean
variable, to choose between running config file for each request
(flexibility), and running config file only once (performance in
persistent environments).

The default value for $per_request_config is 1 (true), which means that
old configuration that require to change per session (like gitolite's)
will keep working.

While at it, make it so evaluate_git_version() is run only once.

Signed-off-by: Jakub Narebski 
Signed-off-by: Junio C Hamano

Merge branch 'cw/gitweb-hilite-config'

2010-10-06T19:10:58+00:00

* cw/gitweb-hilite-config:
  Enable highlight executable path as a configuration option