gitweb(1)
gitweb(1)
NAMN
gitweb - Git-webbgränssnitt (webbfrontend för Git-arkiv)
SYNOPSIS
För att komma igång med gitweb, kör git-instaweb(1) från ett Git-arkiv. Detta kommer att konfigurera och starta din webbserver samt öppna en webbläsare som pekar på gitweb.
BESKRIVNING
Gitweb tillhandahåller ett webbgränssnitt för Git-arkiv. Dess funktioner inkluderar:
- Visning av flera Git-arkiv med gemensam rot.
- Bläddring i varje revision av arkivet.
- Visning av innehållet i filer i arkivet vid valfri revision.
- Visning av revisionsloggen för grenar, historik för filer och kataloger, samt vad som ändrades, när och av vem.
- Visning av blame-/annoteringsdetaljer för valfri fil (om aktiverat).
- Generering av RSS- och Atom-flöden för commits för valfri gren. Flödena kan upptäckas automatiskt i moderna webbläsare.
- Visning av allt som ändrades i en revision, och stegvis genomgång av revisioner medan arkivets historik granskas.
- Sökning efter commits vars commit-meddelanden matchar en given sökterm.
Se https://repo.or.cz/w/git.git/tree/HEAD:/gitweb/ för gitweb-källkoden, bläddrad med gitweb självt.
KONFIGURATION
Olika aspekter av gitwebs beteende kan styras genom konfigurationsfilen gitweb_config.perl eller /etc/gitweb.conf. Se gitweb.conf(5) för detaljer.
Arkiv
Gitweb kan visa information från ett eller flera Git-arkiv. Dessa arkiv måste finnas på det lokala filsystemet och dela en gemensam arkivrot, det vill säga alla måste ligga under en och samma överordnade arkivkatalog (men se också avsnittet "Avancerad webbserverkonfiguration", underavsnittet "Webbserverkonfiguration med flera projektrötter").
our $projectroot = '/sökväg/till/överordnad/katalog';
Standardvärdet för $projectroot är /pub/git. Du kan ändra detta när gitweb byggs via byggkonfigurationsvariabeln GITWEB_PROJECTROOT.
Som standard är alla Git-arkiv under $projectroot synliga och tillgängliga i gitweb. Projektlistan genereras normalt genom att $projectroot genomsöks efter Git-arkiv (mer exakt objektdatabaser; gitweb är inte intresserat av en arbetskatalog och lämpar sig bäst för att visa "nakna" arkiv).
Namnet på arkivet i gitweb är sökvägen till dess $GIT_DIR (dess objektdatabas) relativt till $projectroot. Därför kan arkivet $repo hittas på "$projectroot/$repo".
Filformat för projektlista
I stället för att låta gitweb hitta arkiv genom att skanna filsystemet från $projectroot, kan du tillhandahålla en förgenererad lista över synliga projekt genom att sätta $projects_list så att den pekar på en vanlig textfil med en lista över projekt (med viss ytterligare information).
Denna fil använder följande format:
- En post (för projekt/arkiv) per rad; radfortsättning stöds inte.
- Inledande och avslutande blanksteg ignoreras.
- Fält separeras med blanktecken; varje följd av blanktecken kan användas som fältseparator (reglerna för Perls "split(" ", $line)").
- Fälten använder modifierad URI-kodning, definierad i RFC 3986, avsnitt 2.1 (Percent-Encoding), eller snarare "Query string encoding" (se https://en.wikipedia.org/wiki/Query_string#URL_encoding), med skillnaden att mellanslag kan kodas som "+" (och därför måste även "+" procentkodas).
- Reserverade tecken är: "%" (används för kodning), "+" (kan användas för att koda mellanslag), samt alla blanktecken som definieras i Perl, inklusive mellanslag, tab och radbrytning.
- För närvarande igenkända fält är:
- <arkivsökväg>
- sökväg till arkivets GIT_DIR, relativt till $projectroot
- <arkivägare>
- visas som arkivägare, helst fullständigt namn, eller e-post, eller båda
Du kan generera projektindexfilen med hjälp av åtgärden project_index (länken TXT på sidan med projektlista) direkt från gitweb; se också avsnittet "Generera projektlista med gitweb" nedan.
Exempelinnehåll:
foo.git Joe+R+Hacker+<joe@example.com> foo/bar.git O+W+Ner+<owner@example.org>
Som standard styr denna fil endast vilka projekt som är synliga på sidan med projektlista (observera att poster som inte pekar på korrekt igenkända Git-arkiv inte kommer att visas av gitweb). Även om ett projekt inte är synligt på projektlistesidan kan du ändå visa det genom att manuellt skapa en gitweb-URL. Genom att sätta konfigurationsvariabeln $strict_export (se gitweb.conf(5)) till ett sant värde kan du tillåta visning endast av arkiv som också visas på översiktssidan (det vill säga endast projekt som uttryckligen listas i projektlistfilen kommer att vara åtkomliga).
Generera projektlista med gitweb
Vi antar att GITWEB_CONFIG har sitt standardvärde från Makefile, nämligen gitweb_config.perl. Lägg följande i filen gitweb_make_index.perl:
read_config_file("gitweb_config.perl");
$projects_list = $projectroot;
Skapa sedan följande skript för att få en projektlista i ett format som passar för byggkonfigurationsvariabeln GITWEB_LIST (eller variabeln $projects_list i gitweb-konfigurationen):
#!/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
Kör detta skript och spara dess utdata till en fil. Denna fil kan sedan användas som projektlistfil, vilket innebär att du kan sätta $projects_list till dess filnamn.
Styrning av åtkomst till Git-arkiv
Som standard är alla Git-arkiv under $projectroot synliga och tillgängliga för gitweb. Du kan dock konfigurera hur gitweb styr åtkomsten till arkiv.
- Som beskrivs i avsnittet "Filformat för projektlista" kan du styra vilka projekt som är synliga genom att selektivt inkludera arkiv i projektlistfilen och sätta konfigurationsvariabeln $projects_list så att den pekar på den. Med $strict_export satt kan projektlistfilen också användas för att styra vilka arkiv som är tillgängliga.
- Du kan konfigurera gitweb att endast lista och tillåta visning av uttryckligen exporterade arkiv via variabeln $export_ok i gitwebs konfigurationsfil; se manualsidan gitweb.conf(5). Om den evalueras till sant visar gitweb arkiv endast om filen med namnet $export_ok finns i deras objektdatabas (om katalogen har den magiska filen med namnet $export_ok).
Till exempel tillåter git-daemon(1) som standard (om inte flaggan --export-all används) endast hämtning för de arkiv som har filen git-daemon-export-ok. Om du lägger till
our $export_ok = "git-daemon-export-ok";
så visar och tillåter gitweb endast åtkomst till de arkiv som kan hämtas via protokollet git://.
- Slutligen är det möjligt att ange en godtycklig Perl-subrutin som anropas för varje arkiv för att avgöra om det får exporteras. Subrutinen får en absolut sökväg till projektet (arkivet) som enda parameter (det vill säga "$projectroot/$project").
Till exempel, om du använder mod_perl för att köra skriptet och har konfigurerat enkel HTTP-autentisering för dina arkiv, kan du använda följande hook för att tillåta åtkomst endast om användaren är behörig att läsa filerna:
$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 per arkiv
Du kan konfigurera enskilda arkiv som visas i gitweb genom att skapa en fil i Git-arkivets GIT_DIR eller genom att sätta vissa arkivkonfigurationsvariabler (i GIT_DIR/config, se git-config(1)):
Du kan använda följande filer i arkivet:
- README.html
- En html-fil (HTML-fragment) som inkluderas på gitwebs projektsida summary inuti ett <div>-blockelement. Du kan använda den för en längre projektbeskrivning, för att tillhandahålla länkar (till exempel till projektets hemsida) etc. Detta känns endast igen om XSS-skydd är avstängt ($prevent_xss är falskt, se gitweb.conf(5)); ett sätt att säkert inkludera en README när XSS-skydd är på kan komma att utarbetas i framtiden.
- description (eller gitweb.description)
- Kort (förkortad till $projects_list_description_width på sidan med projektlista, vilket som standard är 25 tecken; se gitweb.conf(5)) enradig beskrivning av ett projekt (ett arkiv). Vanlig textfil; HTML kommer att escapes. Standardvärdet sätts vid skapande av arkivet från mallen till
- Unnamed repository; edit this file to name it for gitweb.
- vanligtvis installerad i /usr/share/git-core/templates/. Du kan använda arkivkonfigurationsvariabeln gitweb.description, men filen har företräde.
- category (eller gitweb.category)
- Enradig kategori för ett projekt, används för att gruppera projekt om $projects_list_group_categories är aktiverad. Som standard (om fil och konfigurationsvariabel saknas) placeras okategoriserade projekt i kategorin $project_list_default_category. Du kan använda arkivkonfigurationsvariabeln gitweb.category, men filen har företräde.
- Konfigurationsvariablerna $projects_list_group_categories och $project_list_default_category beskrivs i gitweb.conf(5).
- cloneurl (eller flervärdesvariabeln gitweb.url)
- Fil med arkivets URL (används för kloning och hämtning), en per rad. Visas på projektets sammanfattningssida. Du kan använda den flervärda arkivkonfigurationsvariabeln gitweb.url för detta, men filen har företräde.
- Detta är en förbättring per arkiv / version av den globala prefixbaserade gitweb-konfigurationsvariabeln @git_base_url_list (se gitweb.conf(5)).
- gitweb.owner
- Du kan använda arkivkonfigurationsvariabeln gitweb.owner för att ange arkivets ägare. Den visas i projektlistan och på sammanfattningssidan.
- Om den inte är satt används ägaren till filsystemkatalogen (via GECOS-fältet, dvs. fältet för riktigt namn från getpwuid(3)) om $projects_list inte är satt (gitweb skannar $projectroot efter arkiv); om $projects_list pekar på en fil med en lista över arkiv så kommer projektägaren som standard från denna fil för det givna arkivet.
- olika gitweb.*-konfigurationsvariabler (i config)
- Läs beskrivningen av hashen %feature för en detaljerad lista och förklaringar. Se också avsnittet "Konfigurera gitweb-funktioner" i gitweb.conf(5)
ÅTGÄRDER OCH URL:ER
Gitweb kan använda URL:er baserade på path_info (komponent), eller skicka all nödvändig information via frågeparametrar. Typiska gitweb-URL:er kan delas upp i fem komponenter:
.../gitweb.cgi/<repo>/<action>/<revision>:/<path>?<arguments>
- repo
- Arkivet som åtgärden ska utföras på.
- Alla åtgärder utom de som listar alla tillgängliga projekt, i vilken form de än visas, kräver denna parameter.
- action
- Åtgärden som ska köras. Standard är projects_list om repo inte är satt, och annars summary.
- revision
- Revision som visas. Standard är HEAD.
- path
- Sökvägen inom <repository> som åtgärden utförs på, för de åtgärder som kräver det.
- arguments
- Argument som styr åtgärdens beteende.
Vissa åtgärder kräver eller tillåter att två revisioner anges, och ibland till och med två sökvägar. I den mest generella formen ser en sådan path_info-baserad gitweb-URL ut så här:
.../gitweb.cgi/<repo>/<action>/<revision-from>:/<path-from>..<revision-to>:/<path-to>?<arguments>
Varje åtgärd implementeras som en subrutin och måste finnas i hashen %actions. Vissa åtgärder är avstängda som standard och måste aktiveras via funktionsmekanismen. För att till exempel aktivera vyn blame, lägg till följande i gitwebs konfigurationsfil:
$feature{'blame'}{'default'} = [1];
Åtgärder
Standardåtgärderna är:
- project_list
- Listar tillgängliga Git-arkiv. Detta är standardkommandot om inget arkiv anges i URL:en.
- summary
- Visar en sammanfattning av ett givet arkiv. Detta är standardkommandot om ingen åtgärd anges i URL:en och endast arkivet är angivet.
- heads, remotes
- Listar alla lokala respektive alla fjärrspårande grenar i ett givet arkiv.
- Den senare är inte tillgänglig som standard, om den inte har konfigurerats.
- tags
- Listar alla taggar (lättvikts- och annoterade) i ett givet arkiv.
- blob, tree
- Visar filer och kataloger i en given sökväg i arkivet vid en given revision. Detta är standardkommandot om ingen åtgärd anges i URL:en och en sökväg anges.
- blob_plain
- Returnerar rådata för filen i det givna arkivet, vid den givna sökvägen och revisionen. Länkar till denna åtgärd markeras som raw.
- blobdiff
- Visar skillnaden mellan två revisioner av samma fil.
- blame, blame_incremental
- Visar blame-information (även kallad annotering) för en fil. Rad för rad visas den revision där raden senast ändrades och den användare som gjorde ändringen.
- Den inkrementella versionen (som, om den är konfigurerad, används automatiskt när JavaScript är aktiverat) använder Ajax för att successivt lägga till blame-information till innehållet i den givna filen.
- Denna åtgärd är avstängd som standard av prestandaskäl.
- commit, commitdiff
- Visar information om en specifik commit i ett arkiv. Vyn commit visar information om commiten mer detaljerat, medan åtgärden commitdiff visar ändringsmängden för den givna commiten.
- patch
- Returnerar commiten i vanligt textbaserat e-postformat, lämpligt för att appliceras med git-am(1).
- tag
- Visar en specifik annoterad tagg (tag-objekt).
- log, shortlog
- Visar logginformation (commit-meddelande eller endast ämnesrad) för en given gren (med start från en given revision).
- Vyn shortlog är mer kompakt; den visar en commit per rad.
- history
- Visar historiken för filen eller katalogen i en given sökväg i arkivet, med start från en given revision (standard är HEAD, det vill säga standardgrenen).
- Denna vy liknar vyn shortlog.
- rss, atom
- Genererar ett RSS- eller Atom-flöde med ändringar i arkivet.
WEBSERVERKONFIGURATION
Detta avsnitt förklarar hur några vanliga webbservrar konfigureras för att köra gitweb. I alla fall syftar /path/to/gitweb i exemplen på katalogen där du installerade gitweb och som innehåller gitweb_config.perl.
Om du har konfigurerat en webbserver som inte listas här för gitweb, skicka gärna in instruktionerna så att de kan inkluderas i en framtida utgåva.
Apache som CGI
Apache måste vara konfigurerad för att stödja CGI-skript i katalogen där gitweb är installerat. Antag att det är katalogen /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>
Med den konfigurationen blir den fullständiga sökvägen för att bläddra i arkiv:
http://server/cgi-bin/gitweb.cgi
Apache med mod_perl, via ModPerl::Registry
Du kan använda mod_perl med gitweb. Du måste installera Apache::Registry (för mod_perl 1.x) eller ModPerl::Registry (för mod_perl 2.x) för att aktivera detta stöd.
Om vi antar att gitweb är installerat i /var/www/perl, är följande Apache-konfiguration (för mod_perl 2.x) lämplig:
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>
Med den konfigurationen blir den fullständiga sökvägen för att bläddra i arkiv:
http://server/perl/gitweb.cgi
Apache med FastCGI
Gitweb fungerar med Apache och FastCGI. Först måste du byta namn på, kopiera eller skapa en symbolisk länk från gitweb.cgi till gitweb.fcgi. Antag att gitweb är installerat i katalogen /usr/share/gitweb. Följande Apache-konfiguration är lämplig (OTESTAD!):
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>
Med den konfigurationen blir den fullständiga sökvägen för att bläddra i arkiv:
http://server/gitweb
AVANCERAD WEBBSERVERKONFIGURATION
Alla dessa exempel använder omskrivning av begäranden och behöver mod_rewrite (eller motsvarande; exemplen nedan är skrivna för Apache).
En enda URL för gitweb och för hämtning
Om du vill ha en enda URL för både gitweb och dina http://-arkiv kan du konfigurera Apache så här:
<VirtualHost *:80>
ServerName git.example.org
DocumentRoot /pub/git
SetEnv GITWEB_CONFIG /etc/gitweb.conf
# slå på mod rewrite
RewriteEngine on
# gör startsidan till en intern omskrivning till gitweb-skriptet
RewriteRule ^/$ /cgi-bin/gitweb.cgi
# få åtkomst för "dumma klienter" att fungera
RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
/cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
</VirtualHost>
Ovanstående konfiguration förutsätter att dina publika arkiv finns under /pub/git och kommer att servera dem som http://git.domain.org/dir-under-pub-git, både som klonbar Git-URL och som bläddringsbart gitweb-gränssnitt. Om du sedan startar din git-daemon(1) med --base-path=/pub/git --export-all kan du till och med använda git://-URL:en med exakt samma sökväg.
Att sätta miljövariabeln GITWEB_CONFIG gör att gitweb använder den namngivna filen (i detta exempel /etc/gitweb.conf) som konfiguration för gitweb. Du behöver egentligen inte detta i ovanstående exempel; det krävs endast om din konfigurationsfil ligger på en annan plats än den inbyggda (vid kompilering av gitweb) gitweb_config.perl eller /etc/gitweb.conf. Se gitweb.conf(5) för detaljer, särskilt information om prioritetsregler.
Om du använder omskrivningsreglerna från exemplet kan du också behöva något i stil med följande i din gitweb-konfigurationsfil (/etc/gitweb.conf enligt exemplet ovan):
@stylesheets = ("/någon/absolut/sökväg/gitweb.css");
$my_uri = "/";
$home_link = "/";
$per_request_config = 1;
Numera bör dock gitweb skapa en HTML base-tagg vid behov (för att sätta bas-URI för relativa länkar), så det bör fungera automatiskt.
Webbserverkonfiguration med flera projektrötter
Om du vill använda gitweb med flera projektrötter kan du redigera din virtuella Apache-värd och gitweb-konfigurationsfiler på följande sätt.
Konfigurationen för den virtuella värden (i Apaches konfigurationsfil) bör se ut så här:
<VirtualHost *:80>
ServerName git.example.org
DocumentRoot /pub/git
SetEnv GITWEB_CONFIG /etc/gitweb.conf
# slå på mod rewrite
RewriteEngine on
# gör startsidan till en intern omskrivning till gitweb-skriptet
RewriteRule ^/$ /cgi-bin/gitweb.cgi [QSA,L,PT]
# leta efter en public_git-katalog i Unix-användares hemkataloger
# 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]
# definierad lista av projektrötter
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]
# få åtkomst för "dumma klienter" att fungera
RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
/cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
</VirtualHost>
Här skickas den faktiska projektrötter till gitweb via miljövariabeln GITWEB_PROJECT_ROOT från webbservern, så du behöver lägga följande rad i gitwebs konfigurationsfil (/etc/gitweb.conf i exemplet ovan):
$projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git";
Observera att detta måste sättas för varje begäran, så antingen måste $per_request_config vara falsk, eller så måste ovanstående ligga i kod som refereras av $per_request_config.
Dessa konfigurationer möjliggör två saker. För det första kan varje Unix-användare (<user>) på servern bläddra i Git-arkiv som finns i ~/public_git/ med följande URL:
http://git.example.org/~<user>/
Om du inte vill ha denna funktion på din server tar du helt enkelt bort den andra omskrivningsregeln.
Om du redan använder mod_userdir i din virtuella värd eller inte vill använda '~' som första tecken, kommentera bort eller ta bort den andra omskrivningsregeln och avkommentera en av de följande beroende på vad du vill ha.
För det andra kommer arkiv som finns i /pub/scm/ och /var/git/ att vara åtkomliga via http://git.example.org/scm/ respektive http://git.example.org/var/. Du kan lägga till så många projektrötter du vill genom att lägga till omskrivningsregler som den tredje och fjärde.
Användning av PATH_INFO
Om du aktiverar användning av PATH_INFO i gitweb genom att lägga till
$feature{'pathinfo'}{'default'} = [1];
i din gitweb-konfigurationsfil, är det möjligt att konfigurera din server så att den tar emot och producerar URL:er i formen
http://git.example.com/project.git/shortlog/sometag
det vill säga utan delen gitweb.cgi, genom att använda en konfiguration som följande. Denna konfiguration antar att /var/www/gitweb är webbserverns DocumentRoot och innehåller skriptet gitweb.cgi samt kompletterande statiska filer (stilmall, favicon, JavaScript):
<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>
Omskrivningsregeln garanterar att befintliga statiska filer serveras korrekt, medan alla andra URL:er skickas till gitweb som PATH_INFO-parameter.
Observera att du i detta fall inte behöver några särskilda inställningar för @stylesheets, $my_uri och $home_link, men du förlorar åtkomsten för "dumma klienter" till dina projektkataloger med ändelsen .git (beskrivet i avsnittet "En enda URL för gitweb och för hämtning"). En möjlig lösning på detta är följande: låt projekten i din projektrötter (t.ex. /pub/git) vara namngivna utan .git-tillägg (t.ex. /pub/git/project i stället för /pub/git/project.git) och konfigurera Apache så här:
<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>
Den extra AliasMatch-regeln gör att
http://git.example.com/project.git
ger rå åtkomst till projektets Git-katalog (så att projektet kan klonas), medan
http://git.example.com/project
ger ett människovänligt gitweb-gränssnitt.
Denna lösning är inte helt vattentät, i den meningen att om ett projekt har en namngiven referens (gren, tagg) som börjar med git/, så kommer sökvägar som
http://git.example.com/project/command/abranch..git/abranch
att misslyckas med ett 404-fel.
FEL
Rapportera gärna fel eller önskemål om funktioner till git@vger.kernel.org[1], med "gitweb" i ämnesraden.
SE ÄVEN
gitweb.conf(5), git-instaweb(1)
gitweb/README, gitweb/INSTALL
GIT
Del av git(1)-sviten
NOTER
1. git@vger.kernel.org
mailto:git@vger.kernel.org
KOLOFON
Denna sida är en del av projektet git (Git distribuerat versionshanteringssystem). Information om projektet finns på ⟨http://git-scm.com/⟩. Om du har en felrapport för denna manualsida, se ⟨http://git-scm.com/community⟩. Denna sida hämtades från projektets uppströms Git-arkiv ⟨https://github.com/git/git.git⟩ den 2026-01-16. (Vid den tidpunkten var datumet för den senaste commit som hittades i arkivet 2026-01-15.) Om du upptäcker renderingsproblem i denna HTML-version av sidan, eller om du anser att det finns en bättre eller mer uppdaterad källa för sidan, eller om du har rättelser eller förbättringar av informationen i denna KOLOFON (som inte är en del av den ursprungliga manualsidan), skicka e-post till man-pages@man7.org
Sidslut
Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/gitweb.1.html
Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på
https://www.linux.se/kontaka-linux-se/
Tack till Datorservice som har sponsrat Linux.se med webbhotell.