зеркало из https://github.com/microsoft/git.git
0cec6db5cf
There are some cases when one line from "raw" git-diff output (raw
format) corresponds to more than one patch in the patchset git-diff
output; we call this situation "split patch". Old code misdetected
subsequent patches (for different files) with the same pre-image and
post-image as fragments of "split patch", leading to mislabeled
from-file/to-file diff header etc.
Old code used pre-image and post-image SHA-1 identifier ('from_id' and
'to_id') to check if current patch corresponds to old raw diff format
line, to find if one difftree raw line coresponds to more than one
patch in the patch format. Now we use post-image filename for that.
This assumes that post-image filename alone can be used to identify
difftree raw line. In the case this changes (which is unlikely
considering current diff engine) we can add 'from_id' and 'to_id'
to detect "patch splitting" together with 'to_file'.
Because old code got pre-image and post-image SHA-1 identifier for the
patch from the "index" line in extended diff header, diff header had
to be buffered. New code takes post-image filename from "git diff"
header, which is first line of a patch; this allows to simplify
git_patchset_body code. A side effect of resigning diff header
buffering is that there is always "diff extended_header" div, even
if extended diff header is empty.
Alternate solution would be to check when git splits patches, and do
not check if parsed info from current patch corresponds to current or
next raw diff format output line. Git splits patches only for 'T'
(typechange) status filepair, and there always two patches
corresponding to one raw diff line. It was not used because it would
tie gitweb code to minute details of git diff output.
While at it, use newly introduced parsed_difftree_line wrapper
subroutine in git_difftree_body.
Noticed-by: Yann Dirson <ydirson@altern.org>
Diagnosed-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
||
|---|---|---|
| .. | ||
| test | ||
| INSTALL | ||
| README | ||
| git-favicon.png | ||
| git-logo.png | ||
| gitweb.css | ||
| gitweb.perl | ||
README
GIT web Interface
=================
The one working on:
http://www.kernel.org/git/
From the git version 1.4.0 gitweb is bundled with git.
How to configure gitweb for your local system
---------------------------------------------
You can specify the following configuration variables when building GIT:
* GITWEB_SITENAME
Shown in the title of all generated pages, defaults to the servers name.
* GITWEB_PROJECTROOT
The root directory for all projects shown by gitweb.
* GITWEB_LIST
points to a directory to scan for projects (defaults to project root)
or to a file for explicit listing of projects.
* GITWEB_HOMETEXT
points to an .html file which is included on the gitweb project
overview page.
* GITWEB_CSS
Points to the location where you put gitweb.css on your web server.
* GITWEB_LOGO
Points to the location where you put git-logo.png on your web server.
* GITWEB_CONFIG
This file will be loaded using 'require' and can be used to override any
of the options above as well as some other options - see the top of
'gitweb.cgi' for their full list and description. If the environment
$GITWEB_CONFIG is set when gitweb.cgi is executed the file in the
environment variable will be loaded instead of the file
specified when gitweb.cgi was created.
Runtime gitweb configuration
----------------------------
You can adjust gitweb behaviour using the file specified in `GITWEB_CONFIG`
(defaults to 'gitweb_config.perl' in the same directory as the CGI).
See the top of 'gitweb.cgi' for the list of variables and some description.
The most notable thing that is not configurable at compile time are the
optional features, stored in the '%features' variable. You can find further
description on how to reconfigure the default features setting in your
`GITWEB_CONFIG` or per-project in `project.git/config` inside 'gitweb.cgi'.
Webserver configuration
-----------------------
If you want to have one URL for both gitweb and your http://
repositories, you can configure apache like this:
<VirtualHost www:80>
ServerName git.domain.org
DocumentRoot /pub/git
RewriteEngine on
RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
SetEnv GITWEB_CONFIG /etc/gitweb.conf
</VirtualHost>
The above configuration expects your public repositories to live under
/pub/git and will serve them as http://git.domain.org/dir-under-pub-git,
both as cloneable GIT URL and as browseable gitweb interface.
If you then start your git-daemon with --base-path=/pub/git --export-all
then you can even use the git:// URL with exactly the same path.
Setting the environment variable GITWEB_CONFIG will tell gitweb to use
the named file (i.e. in this example /etc/gitweb.conf) as a
configuration for gitweb. Perl variables defined in here will
override the defaults given at the head of the gitweb.perl (or
gitweb.cgi). Look at the comments in that file for information on
which variables and what they mean.
Originally written by:
Kay Sievers <kay.sievers@vrfy.org>
Any comment/question/concern to:
Git mailing list <git@vger.kernel.org>