English ▾ Themen ▾ Neueste Version ▾ gitweb zuletzt aktualisiert in 2.50.0

NAME

gitweb - Git Web Interface (Web Frontend für Git Repositories)

SYNOPSIS

Um mit gitweb zu starten, führen Sie git-instaweb[1] aus einem Git-Repository aus. Dies konfiguriert und startet Ihren Webserver und öffnet einen Webbrowser, der auf gitweb zeigt.

BESCHREIBUNG

Gitweb bietet eine Web-Oberfläche für Git-Repositories. Seine Funktionen umfassen

  • Anzeige mehrerer Git-Repositories mit gemeinsamem Stammverzeichnis.

  • Durchsuchen jeder Revision des Repositorys.

  • Anzeige des Inhalts von Dateien im Repository zu jeder beliebigen Revision.

  • Anzeige des Revisionsprotokolls von Branches, der Historie von Dateien und Verzeichnissen, sowie was wann und von wem geändert wurde.

  • Anzeige von Blame-/Annotationdetails für jede Datei (falls aktiviert).

  • Generierung von RSS- und Atom-Feeds von Commits für jeden Branch. Die Feeds sind in modernen Webbrowsern automatisch erkennbar.

  • Anzeige aller Änderungen in einer Revision und schrittweises Durchlaufen von Revisionen, um die Historie des Repositorys anzuzeigen.

  • Finden von Commits, deren Commit-Nachrichten einem gegebenen Suchbegriff entsprechen.

Siehe https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/ für den gitweb-Quellcode, durchsucht mit gitweb selbst.

KONFIGURATION

Verschiedene Aspekte des Verhaltens von gitweb können über die Konfigurationsdatei gitweb_config.perl oder /etc/gitweb.conf gesteuert werden. Details finden Sie in der gitweb.conf[5].

Repositories

Gitweb kann Informationen aus einem oder mehreren Git-Repositories anzeigen. Diese Repositories müssen sich alle auf dem lokalen Dateisystem befinden und einen gemeinsamen Repository-Stamm teilen, d. h. alle unter einem einzigen Eltern-Repository liegen (siehe auch den Abschnitt "Erweiterte Webserver-Einrichtung", Unterabschnitt "Webserver-Konfiguration mit mehreren Projektstämmen").

our $projectroot = '/path/to/parent/directory';

Der Standardwert für $projectroot ist /pub/git. Sie können ihn beim Kompilieren von gitweb über die Build-Konfigurationsvariable GITWEB_PROJECTROOT ändern.

Standardmäßig sind alle Git-Repositories unter $projectroot für gitweb sichtbar und verfügbar. Die Liste der Projekte wird standardmäßig durch Scannen des $projectroot-Verzeichnisses nach Git-Repositories generiert (genauer gesagt nach Objektdatenbanken; gitweb interessiert sich nicht für einen Arbeitsbereich und ist am besten geeignet, "bare" Repositories anzuzeigen).

Der Name des Repositorys in gitweb ist der Pfad zu seiner $GIT_DIR (seiner Objektdatenbank) relativ zu $projectroot. Daher ist das Repository $repo unter "$projectroot/$repo" zu finden.

Format der Projektlistendatei

Anstatt gitweb Repositories durch Scannen des Dateisystems ab $projectroot finden zu lassen, können Sie eine vorab generierte Liste sichtbarer Projekte bereitstellen, indem Sie $projects_list so setzen, dass es auf eine reine Textdatei mit einer Liste von Projekten (mit zusätzlichen Informationen) zeigt.

Diese Datei verwendet das folgende Format

  • Ein Datensatz (für Projekt / Repository) pro Zeile; unterstützt keine Zeilenfortsetzung (Newline-Escaping).

  • Führende und nachgestellte Leerzeichen werden ignoriert.

  • Leerzeichen-getrennte Felder; jede Leerzeichen-Sequenz kann als Feldtrenner verwendet werden (Regeln für Perls "split(" ", $line)").

  • Felder verwenden eine modifizierte URI-Kodierung, wie in RFC 3986, Abschnitt 2.1 (Percent-Encoding) definiert, oder besser gesagt "Query-String-Kodierung" (siehe https://en.wikipedia.org/wiki/Query_string#URL_encoding), der Unterschied besteht darin, dass SP (" ") als "+" kodiert werden kann (und daher "+" ebenfalls prozentkodiert werden muss).

    Reservierte Zeichen sind: "%" (für Kodierung verwendet), "+" (kann zur Kodierung von SPACE verwendet werden), alle Leerzeichen, wie in Perl definiert, einschließlich SP, TAB und LF (zur Trennung von Feldern in einem Datensatz verwendet).

  • Aktuell erkannte Felder sind

    <Repository-Pfad>

    Pfad zur Repository-GIT_DIR, relativ zu $projectroot

    <Repository-Besitzer>

    wird als Repository-Besitzer angezeigt, vorzugsweise vollständiger Name, oder E-Mail, oder beides

Sie können die Projektlisten-Indexdatei über die Aktion `project_index` (der Link *TXT* auf der Projektlisten-Seite) direkt aus gitweb generieren; siehe auch den Abschnitt "Generieren von Projektlisten mit gitweb" unten.

Beispielinhalt

foo.git       Joe+R+Hacker+<joe@example.com>
foo/bar.git   O+W+Ner+<owner@example.org>

Standardmäßig steuert diese Datei nur, welche Projekte auf der Projektlisten-Seite sichtbar sind (beachten Sie, dass Einträge, die nicht auf korrekt erkannte Git-Repositories zeigen, von gitweb nicht angezeigt werden). Auch wenn ein Projekt nicht auf der Projektlisten-Seite sichtbar ist, können Sie es trotzdem anzeigen, indem Sie eine gitweb-URL manuell erstellen. Indem Sie die Konfigurationsvariable $strict_export (siehe gitweb.conf[5]) auf einen wahren Wert setzen, können Sie nur die Anzeige von Repositories zulassen, die auch auf der Übersichtsseite angezeigt werden (d. h. nur explizit in der Projektlistendatei aufgeführte Projekte sind zugänglich).

Generieren von Projektlisten mit gitweb

Wir gehen davon aus, dass GITWEB_CONFIG den Standard-Makefile-Wert hat, nämlich gitweb_config.perl. Fügen Sie Folgendes in die Datei gitweb_make_index.perl ein

read_config_file("gitweb_config.perl");
$projects_list = $projectroot;

Erstellen Sie dann das folgende Skript, um eine Liste von Projekten im Format zu erhalten, das für die GITWEB_LIST Build-Konfigurationsvariable (oder die Variable $projects_list in der gitweb-Konfiguration) geeignet ist

#!/bin/sh

export GITWEB_CONFIG="gitweb_make_index.perl"
export GATEWAY_INTERFACE="CGI/1.1"
export HTTP_ACCEPT="*/*"
export REQUEST_METHOD="GET"
export QUERY_STRING="a=project_index"

perl -- /var/www/cgi-bin/gitweb.cgi

Führen Sie dieses Skript aus und speichern Sie seine Ausgabe in einer Datei. Diese Datei könnte dann als Projektlistendatei verwendet werden, was bedeutet, dass Sie $projects_list auf ihren Dateinamen setzen können.

Zugriffskontrolle auf Git-Repositories

Standardmäßig sind alle Git-Repositories unter $projectroot für gitweb sichtbar und verfügbar. Sie können jedoch konfigurieren, wie gitweb den Zugriff auf Repositories steuert.

  • Wie im Abschnitt "Format der Projektlistendatei" beschrieben, können Sie steuern, welche Projekte sichtbar sind, indem Sie Repositories selektiv in die Projektlistendatei aufnehmen und die gitweb-Konfigurationsvariable $projects_list auf diese Datei setzen. Wenn $strict_export gesetzt ist, kann die Projektlistendatei auch dazu verwendet werden, zu steuern, welche Repositories verfügbar sind.

  • Sie können gitweb so konfigurieren, dass nur explizit exportierte Repositories aufgelistet und deren Anzeige zugelassen wird, über die Variable $export_ok in der gitweb-Konfigurationsdatei; siehe Manpage gitweb.conf[5]. Wenn sie wahr ausgewertet wird, zeigt gitweb Repositories nur an, wenn diese Datei, die durch $export_ok benannt ist, in ihrer Objektdatenbank existiert (wenn das Verzeichnis die magische Datei namens $export_ok hat).

    Zum Beispiel erlaubt git-daemon[1] standardmäßig (es sei denn, die Option --export-all wird verwendet) das Abrufen nur für die Repositories, die eine Datei git-daemon-export-ok haben. Hinzufügen von

    our $export_ok = "git-daemon-export-ok";

    lässt gitweb nur die Repositories anzeigen und den Zugriff darauf zulassen, die über das Protokoll git:// abgerufen werden können.

  • Schließlich ist es möglich, eine beliebige Perl-Subroutine anzugeben, die für jedes Repository aufgerufen wird, um zu bestimmen, ob es exportiert werden kann. Die Subroutine erhält einen absoluten Pfad zum Projekt (Repository) als einzigen Parameter (d.h. "$projectroot/$project").

    Wenn Sie zum Beispiel mod_perl zum Ausführen des Skripts verwenden und die Authentifizierung für dumme HTTP-Protokolle für Ihre Repositories konfiguriert haben, können Sie den folgenden Hook verwenden, um den Zugriff nur zuzulassen, wenn der Benutzer zum Lesen der Dateien berechtigt ist

    $export_auth_hook = sub {
	use Apache2::SubRequest ();
	use Apache2::Const -compile => qw(HTTP_OK);
	my $path = "$_[0]/HEAD";
	my $r    = Apache2::RequestUtil->request;
	my $sub  = $r->lookup_file($path);
	return $sub->filename eq $path
	    && $sub->status == Apache2::Const::HTTP_OK;
};

Gitweb-Konfiguration pro Repository

Sie können einzelne Repositories, die in gitweb angezeigt werden, konfigurieren, indem Sie eine Datei im GIT_DIR des Git-Repositorys erstellen oder eine Repository-Konfigurationsvariable setzen (in GIT_DIR/config, siehe git-config[1]).

Sie können die folgenden Dateien in einem Repository verwenden

README.html

Eine HTML-Datei (HTML-Fragment), die auf der "Zusammenfassungs"-Seite des gitweb-Projekts innerhalb eines <div>-Blockelements eingefügt wird. Sie können sie für eine längere Beschreibung eines Projekts, für Links (z.B. zur Homepage des Projekts) usw. verwenden. Dies wird nur erkannt, wenn der XSS-Schutz deaktiviert ist ($prevent_xss ist falsch, siehe gitweb.conf[5]); eine Möglichkeit, ein README sicher einzufügen, wenn der XSS-Schutz aktiviert ist, mag in Zukunft entwickelt werden.

description (oder gitweb.description)

Kurze (gekürzt auf $projects_list_description_width auf der Projektlisten-Seite, was standardmäßig 25 Zeichen sind; siehe gitweb.conf[5]) einzeilige Beschreibung eines Projekts (eines Repositorys). Nur-Text-Datei; HTML wird maskiert. Standardmäßig auf

Unnamed repository; edit this file to name it for gitweb.

vom Template während der Repository-Erstellung gesetzt, normalerweise installiert in /usr/share/git-core/templates/. Sie können die Repository-Konfigurationsvariable gitweb.description verwenden, aber die Datei hat Vorrang.

category (oder gitweb.category)

Einzeilige Kategorie eines Projekts, die zur Gruppierung von Projekten verwendet wird, wenn $projects_list_group_categories aktiviert ist. Standardmäßig (Datei und Konfigurationsvariable nicht vorhanden) werden nicht kategorisierte Projekte in die Kategorie $project_list_default_category eingeordnet. Sie können die Repository-Konfigurationsvariable gitweb.category verwenden, aber die Datei hat Vorrang.

Die Konfigurationsvariablen $projects_list_group_categories und $project_list_default_category werden in gitweb.conf[5] beschrieben.

cloneurl (oder mehrwertige gitweb.url)

Datei mit der Repository-URL (für Klonen und Abrufen verwendet), eine pro Zeile. Wird auf der Projektübersichtsseite angezeigt. Sie können dafür die mehrwertige Repository-Konfigurationsvariable gitweb.url verwenden, aber die Datei hat Vorrang.

Dies ist eine Repository-spezifische Erweiterung / Version der globalen präfixbasierten Gitweb-Konfigurationsvariable @git_base_url_list (siehe gitweb.conf[5]).

gitweb.owner

Sie können die Repository-Konfigurationsvariable gitweb.owner verwenden, um den Besitzer eines Repositorys festzulegen. Er wird in der Projektliste und auf der Übersichtsseite angezeigt.

Wenn er nicht gesetzt ist, wird der Besitzer des Dateisystemverzeichnisses verwendet (über das GECOS-Feld, d.h. das Feld für den echten Namen von getpwuid(3)), wenn $projects_list nicht gesetzt ist (gitweb scannt $projectroot nach Repositories); wenn $projects_list auf eine Datei mit einer Liste von Repositories zeigt, dann ist der Projektbesitzer standardmäßig der Wert aus dieser Datei für das jeweilige Repository.

verschiedene gitweb.* Konfigurationsvariablen (in config)

Lesen Sie die Beschreibung des %feature-Hashes für eine detaillierte Liste und Beschreibungen. Siehe auch den Abschnitt "Konfigurieren von Gitweb-Funktionen" in gitweb.conf[5].

AKTIONEN UND URLS

Gitweb kann Pfad-Info (Komponenten)-basierte URLs verwenden oder alle notwendigen Informationen über Query-Parameter übergeben. Die typischen gitweb-URLs werden in fünf Komponenten aufgeteilt

.../gitweb.cgi/<repo>/<action>/<revision>:/<path>?<arguments>
repo

Das Repository, auf dem die Aktion ausgeführt wird.

Alle Aktionen außer denen, die alle verfügbaren Projekte in irgendeiner Form auflisten, erfordern diesen Parameter.

action

Die auszuführende Aktion. Standardmäßig projects_list, wenn kein Repository gesetzt ist, und ansonsten summary.

revision

Angezeigte Revision. Standardmäßig HEAD.

path

Der Pfad innerhalb des <repository>, auf dem die Aktion ausgeführt wird, für die Aktionen, die ihn erfordern.

arguments

Alle Argumente, die das Verhalten der Aktion steuern.

Einige Aktionen erfordern oder erlauben die Angabe von zwei Revisionen und manchmal sogar zwei Pfadnamen. In der allgemeinsten Form sieht eine solche Pfad-Info (Komponenten)-basierte gitweb-URL so aus

.../gitweb.cgi/<repo>/<action>/<revision-from>:/<path-from>..<revision-to>:/<path-to>?<arguments>

Jede Aktion wird als Unterroutine implementiert und muss im %actions-Hash vorhanden sein. Einige Aktionen sind standardmäßig deaktiviert und müssen über den Feature-Mechanismus aktiviert werden. Um zum Beispiel die Ansicht blame zu aktivieren, fügen Sie Folgendes zur gitweb-Konfigurationsdatei hinzu

$feature{'blame'}{'default'} = [1];

Aktionen

Die Standardaktionen sind

project_list

Listet die verfügbaren Git-Repositories auf. Dies ist der Standardbefehl, wenn kein Repository in der URL angegeben ist.

summary

Zeigt eine Zusammenfassung des angegebenen Repositorys an. Dies ist der Standardbefehl, wenn keine Aktion in der URL angegeben ist und nur das Repository angegeben ist.

heads
remotes

Listet alle lokalen oder alle Remote-Tracking-Branches in einem bestimmten Repository auf.

Letzteres ist standardmäßig nicht verfügbar, es sei denn, es ist konfiguriert.

tags

Listet alle Tags (leichtgewichtige und annotierte) in einem bestimmten Repository auf.

blob
tree

Zeigt die Dateien und Verzeichnisse in einem bestimmten Repository-Pfad zu einer gegebenen Revision an. Dies ist der Standardbefehl, wenn keine Aktion in der URL angegeben ist und ein Pfad angegeben ist.

blob_plain

Gibt die Rohdaten für die Datei in einem bestimmten Repository, an einem bestimmten Pfad und zu einer bestimmten Revision zurück. Links zu dieser Aktion sind als raw markiert.

blobdiff

Zeigt den Unterschied zwischen zwei Revisionen derselben Datei an.

blame
blame_incremental

Zeigt die Blame- (auch Annotations-) Informationen für eine Datei an. Zeilenweise wird die Revision angezeigt, in der diese Zeile zuletzt geändert wurde, und der Benutzer, der die Änderung committet hat. Die inkrementelle Version (die bei aktivierter JavaScript-Unterstützung automatisch verwendet wird, falls konfiguriert) verwendet Ajax, um die Blame-Informationen inkrementell zum Inhalt der gegebenen Datei hinzuzufügen.

Diese Aktion ist aus Leistungsgründen standardmäßig deaktiviert.

commit
commitdiff

Zeigt Informationen über einen bestimmten Commit in einem Repository an. Die Ansicht commit zeigt detailliertere Informationen zum Commit an, die Aktion commitdiff zeigt die Änderungen (changeset) für den gegebenen Commit an.

patch

Gibt den Commit im Klartext-Mail-Format zurück, geeignet für die Anwendung mit git-am[1].

tag

Zeigt einen bestimmten annotierten Tag (Tag-Objekt) an.

log
shortlog

Zeigt Log-Informationen (Commit-Nachricht oder nur Commit-Betreff) für einen bestimmten Branch (beginnend mit der angegebenen Revision) an.

Die Ansicht shortlog ist kompakter; sie zeigt einen Commit pro Zeile.

history

Zeigt die Historie einer Datei oder eines Verzeichnisses in einem bestimmten Repository-Pfad an, beginnend mit der angegebenen Revision (standardmäßig HEAD, d. h. der Standard-Branch).

Diese Ansicht ist ähnlich der shortlog-Ansicht.

rss
atom

Generiert einen RSS- (oder Atom-) Feed von Änderungen an einem Repository.

WEBserver-KONFIGURATION

Dieser Abschnitt erklärt, wie gängige Webserver für gitweb konfiguriert werden. In allen Fällen ist /path/to/gitweb in den Beispielen das Verzeichnis, in dem Sie gitweb installiert haben und das gitweb_config.perl enthält.

Wenn Sie einen Webserver für gitweb konfiguriert haben, der hier nicht aufgeführt ist, senden Sie bitte die Anweisungen, damit sie in zukünftigen Versionen aufgenommen werden können.

Apache als CGI

Apache muss so konfiguriert sein, dass er CGI-Skripte im Verzeichnis, in dem gitweb installiert ist, unterstützt. Nehmen wir an, dies ist das Verzeichnis /var/www/cgi-bin.

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

<Directory "/var/www/cgi-bin">
    Options Indexes FollowSymlinks ExecCGI
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Mit dieser Konfiguration wäre der vollständige Pfad zum Durchsuchen von Repositories

http://server/cgi-bin/gitweb.cgi

Apache mit mod_perl, über ModPerl::Registry

Sie können mod_perl mit gitweb verwenden. Sie müssen Apache::Registry (für mod_perl 1.x) oder ModPerl::Registry (für mod_perl 2.x) installieren, um diese Unterstützung zu aktivieren.

Unter der Annahme, dass gitweb nach /var/www/perl installiert wurde, ist die folgende Apache-Konfiguration (für mod_perl 2.x) geeignet.

Alias /perl "/var/www/perl"

<Directory "/var/www/perl">
    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    PerlOptions +ParseHeaders
    Options Indexes FollowSymlinks +ExecCGI
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Mit dieser Konfiguration wäre der vollständige Pfad zum Durchsuchen von Repositories

http://server/perl/gitweb.cgi

Apache mit FastCGI

Gitweb funktioniert mit Apache und FastCGI. Zuerst müssen Sie gitweb.cgi in gitweb.fcgi umbenennen, kopieren oder verlinken. Nehmen wir an, gitweb ist im Verzeichnis /usr/share/gitweb installiert. Die folgende Apache-Konfiguration ist geeignet (UNGETESTET!)

FastCgiServer /usr/share/gitweb/gitweb.cgi
ScriptAlias /gitweb /usr/share/gitweb/gitweb.cgi

Alias /gitweb/static /usr/share/gitweb/static
<Directory /usr/share/gitweb/static>
    SetHandler default-handler
</Directory>

Mit dieser Konfiguration wäre der vollständige Pfad zum Durchsuchen von Repositories

http://server/gitweb

ERWEITERTE WEBserver-EINRICHTUNG

Alle diese Beispiele verwenden Request Rewriting und benötigen mod_rewrite (oder ein Äquivalent; Beispiele unten sind für Apache geschrieben).

Einzelne URL für gitweb und zum Abrufen

Wenn Sie eine URL sowohl für gitweb als auch für Ihre http://-Repositories haben möchten, können Sie Apache wie folgt konfigurieren

<VirtualHost *:80>
    ServerName    git.example.org
    DocumentRoot  /pub/git
    SetEnv        GITWEB_CONFIG   /etc/gitweb.conf

    # turning on mod rewrite
    RewriteEngine on

    # make the front page an internal rewrite to the gitweb script
    RewriteRule ^/$  /cgi-bin/gitweb.cgi

    # make access for "dumb clients" work
    RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
		/cgi-bin/gitweb.cgi%{REQUEST_URI}  [L,PT]
</VirtualHost>

Die obige Konfiguration erwartet, dass Ihre öffentlichen Repositories unter /pub/git liegen, und wird sie sowohl als klonbare Git-URL als auch als durchsuchbare gitweb-Schnittstelle als http://git.domain.org/dir-under-pub-git bereitstellen. Wenn Sie dann Ihren git-daemon[1] mit --base-path=/pub/git --export-all starten, können Sie auch die git://-URL mit genau demselben Pfad verwenden.

Das Setzen der Umgebungsvariable GITWEB_CONFIG weist gitweb an, die benannte Datei (d.h. in diesem Beispiel /etc/gitweb.conf) als Konfiguration für gitweb zu verwenden. Sie benötigen sie im obigen Beispiel nicht wirklich; sie ist nur erforderlich, wenn Ihre Konfigurationsdatei an einem anderen Ort als die eingebaute (während des Kompilierens von gitweb) gitweb_config.perl oder /etc/gitweb.conf liegt. Siehe gitweb.conf[5] für Details, insbesondere Informationen zu Vorrangregeln.

Wenn Sie die Rewrite-Regeln aus dem Beispiel verwenden, benötigen Sie möglicherweise auch etwas wie das Folgende in Ihrer gitweb-Konfigurationsdatei (/etc/gitweb.conf im folgenden Beispiel)

@stylesheets = ("/some/absolute/path/gitweb.css");
$my_uri    = "/";
$home_link = "/";
$per_request_config = 1;

Heutzutage sollte gitweb jedoch bei Bedarf ein HTML-Basis-Tag erstellen (um die Basis-URI für relative Links festzulegen), sodass es automatisch funktionieren sollte.

Webserver-Konfiguration mit mehreren Projektstämmen

Wenn Sie gitweb mit mehreren Projektstämmen verwenden möchten, können Sie Ihre Apache-virtuellen Hosts und gitweb-Konfigurationsdateien wie folgt bearbeiten.

Die Konfiguration des virtuellen Hosts (in der Apache-Konfigurationsdatei) sollte wie folgt aussehen

<VirtualHost *:80>
    ServerName    git.example.org
    DocumentRoot  /pub/git
    SetEnv        GITWEB_CONFIG  /etc/gitweb.conf

    # turning on mod rewrite
    RewriteEngine on

    # make the front page an internal rewrite to the gitweb script
    RewriteRule ^/$  /cgi-bin/gitweb.cgi  [QSA,L,PT]

    # look for a public_git directory in unix users' home
    # http://git.example.org/~<user>/
    RewriteRule ^/\~([^\/]+)(/|/gitweb.cgi)?$	/cgi-bin/gitweb.cgi \
		[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]

    # http://git.example.org/+<user>/
    #RewriteRule ^/\+([^\/]+)(/|/gitweb.cgi)?$	/cgi-bin/gitweb.cgi \
		 [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]

    # http://git.example.org/user/<user>/
    #RewriteRule ^/user/([^\/]+)/(gitweb.cgi)?$	/cgi-bin/gitweb.cgi \
		 [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]

    # defined list of project roots
    RewriteRule ^/scm(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
		[QSA,E=GITWEB_PROJECTROOT:/pub/scm/,L,PT]
    RewriteRule ^/var(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
		[QSA,E=GITWEB_PROJECTROOT:/var/git/,L,PT]

    # make access for "dumb clients" work
    RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
		/cgi-bin/gitweb.cgi%{REQUEST_URI}  [L,PT]
</VirtualHost>

Hier wird der tatsächliche Projektstamm über die Umgebungsvariable GITWEB_PROJECT_ROOT vom Webserver an gitweb übergeben, sodass Sie die folgende Zeile in die gitweb-Konfigurationsdatei (/etc/gitweb.conf im obigen Beispiel) einfügen müssen

$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git";

Hinweis, dass dies für jede Anfrage gesetzt werden muss, sodass entweder $per_request_config falsch sein muss oder das Obige in Code gesetzt werden muss, auf das von $per_request_config verwiesen wird;

Diese Konfigurationen ermöglichen zwei Dinge. Erstens kann jeder Unix-Benutzer (<user>) des Servers gitweb Git-Repositories, die in ~/public_git/ gefunden werden, mit der folgenden URL durchsuchen

http://git.example.org/~<user>/

Wenn Sie diese Funktion auf Ihrem Server nicht wünschen, entfernen Sie die zweite Rewrite-Regel.

Wenn Sie bereits mod_userdir in Ihrem virtuellen Host verwenden oder das '~' nicht als erstes Zeichen verwenden möchten, kommentieren Sie einfach die zweite Rewrite-Regel aus oder entfernen Sie sie und kommentieren Sie eine der folgenden Zeilen aus, je nachdem, was Sie möchten.

Zweitens werden Repositories, die unter /scm/ und /var/git/ gefunden werden, über http://git.example.org/scm/ und http://git.example.org/var/ zugänglich sein. Sie können so viele Projektstämme hinzufügen, wie Sie möchten, indem Sie Rewrite-Regeln wie die dritte und vierte hinzufügen.

PATH_INFO-Nutzung

Wenn Sie die PATH_INFO-Nutzung in gitweb aktivieren, indem Sie

$feature{'pathinfo'}{'default'} = [1];

in Ihrer gitweb-Konfigurationsdatei platzieren, ist es möglich, Ihren Server so einzurichten, dass er URLs im folgenden Format konsumiert und erzeugt

http://git.example.com/project.git/shortlog/sometag

d. h. ohne den Teil gitweb.cgi, indem Sie eine Konfiguration wie die folgende verwenden. Diese Konfiguration geht davon aus, dass /var/www/gitweb das DocumentRoot Ihres Webservers ist, das Skript gitweb.cgi und ergänzende statische Dateien (Stylesheet, Favicon, JavaScript) enthält.

<VirtualHost *:80>
	ServerAlias git.example.com

	DocumentRoot /var/www/gitweb

	<Directory /var/www/gitweb>
		Options ExecCGI
		AddHandler cgi-script cgi

		DirectoryIndex gitweb.cgi

		RewriteEngine On
		RewriteCond %{REQUEST_FILENAME} !-f
		RewriteCond %{REQUEST_FILENAME} !-d
		RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
	</Directory>
</VirtualHost>

Die Rewrite-Regel garantiert, dass vorhandene statische Dateien korrekt bedient werden, während jede andere URL als PATH_INFO-Parameter an gitweb übergeben wird.

Hinweis, dass Sie in diesem Fall keine speziellen Einstellungen für @stylesheets, $my_uri und $home_link benötigen, aber Sie verlieren den Zugriff auf Ihre Projekt-.git-Verzeichnisse für "dumme Clients" (beschrieben im Abschnitt "Einzelne URL für gitweb und zum Abrufen"). Eine mögliche Abhilfe hierfür ist folgende: In Ihrem Projektstammverzeichnis (z.B. /pub/git) haben Sie die Projekte benannt, ohne die Endung .git (z.B. /pub/git/project anstelle von /pub/git/project.git) und konfigurieren Sie Apache wie folgt

<VirtualHost *:80>
	ServerAlias git.example.com

	DocumentRoot /var/www/gitweb

	AliasMatch ^(/.*?)(\.git)(/.*)?$ /pub/git$1$3
	<Directory /var/www/gitweb>
		Options ExecCGI
		AddHandler cgi-script cgi

		DirectoryIndex gitweb.cgi

		RewriteEngine On
		RewriteCond %{REQUEST_FILENAME} !-f
		RewriteCond %{REQUEST_FILENAME} !-d
		RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
	</Directory>
</VirtualHost>

Das zusätzliche AliasMatch sorgt dafür, dass

http://git.example.com/project.git

rohen Zugriff auf das Git-Verzeichnis des Projekts (damit das Projekt geklont werden kann) ergibt, während

http://git.example.com/project

menschfreundlichen gitweb-Zugriff bietet.

Diese Lösung ist nicht 100% narrensicher, da, wenn ein Projekt einen benannten Ref (Branch, Tag) hat, der mit git/ beginnt, Pfade wie

http://git.example.com/project/command/abranch..git/abranch

mit einem 404-Fehler fehlschlagen.

BUGS

Bitte melden Sie Fehler oder Funktionswünsche an git@vger.kernel.org und setzen Sie "gitweb" in den Betreff der E-Mail.

SIEHE AUCH

gitweb.conf[5], git-instaweb[1]

gitweb/README, gitweb/INSTALL

GIT

Teil der git[1] Suite