This changes slightly the behavior of gitweb, so that it verifies
that the box isn't inundated with before attempting to serve gitweb.
If the box is overloaded, it basically returns a 503 Server Unavailable
until the load falls below the defined threshold. This helps dramatically
if you have a box that's I/O bound, reaches a certain load and you
don't want gitweb, the I/O hog that it is, increasing the pain the
server is already undergoing.
This behavior is controlled by $maxload configuration variable.
Default is a load of 300, which for most cases should never be hit.
Unset it (set it to undefined value, i.e. undef) to turn off checking.
Currently it requires that '/proc/loadavg' file exists, otherwise the
load check is bypassed (load is taken to be 0). So platforms that do
not implement '/proc/loadavg' currently cannot use this feature
(provisions are included for additional checks to be added by others).
There is simple test in t/t9501-gitweb-standalone-http-status.sh to
check that it correctly returns "503 Service Unavailable" if load is
too high, and also if there are any Perl warnings or errors.
Signed-off-by: John 'Warthog9' Hawley <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Sun, 24 Jan 2010 18:05:23 +0000 (19:05 +0100)]
gitweb.js: Workaround for IE8 bug
In Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses
JavaScript to generate blame info using AJAX, sometimes hang at the
beginning (at 0%) of blaming, e.g. for larger files with long history
like git's own gitweb/gitweb.perl.
The error shown by JavaScript console is "Unspecified error" at char:2
of the following line in gitweb/gitweb.js:
if (xhr.readyState === 3 && xhr.status !== 200) {
Debugging it using IE8 JScript debuger shown that the error occurs
when trying to access xhr.status (xhr is XMLHttpRequest object).
Watch for xhr object shows 'Unspecified error.' as "value" of
xhr.status, and trying to access xhr.status from console throws error.
This bug is some intermittent bug, depending on XMLHttpRequest timing,
as it doesn't occur in all cases. It is probably caused by the fact
that handleResponse is called from timer (pollTimer), to work around
the fact that some browsers call onreadystatechange handler only once
for each state change, and not like required for 'blame_incremental'
as soon as new data is available from server. It looks like xhr
object is not properly initialized; still it is a bug to throw an
error when accessing xhr.status (and not use 'null' or 'undefined' as
value).
Work around this bug in IE8 by using try-catch block when accessing
xhr.status.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Thu, 26 Nov 2009 20:12:15 +0000 (21:12 +0100)]
gitweb: Make linking to actions requiring JavaScript a feature
Let gitweb turn some links (like 'blame' links) into linking to actions
which require JavaScript (like 'blame_incremental' action) only if
'javascript-actions' feature is enabled.
This means that links to such actions would be present only if both
JavaScript is enabled and 'javascript-actions' feature is enabled.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Stephen Boyd [Wed, 25 Nov 2009 03:51:40 +0000 (19:51 -0800)]
gitweb.js: fix padLeftStr() and its usage
It seems that in Firefox-3.5 inserting with javascript inserts the
literal instead of a space. Fix this by inserting the unicode
representation for instead.
Also fix the off-by-one error in the padding calculation that was
causing one less space to be inserted than was requested by the caller.
Signed-off-by: Stephen Boyd <redacted> Cc: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
It is (probably) caused by the fact that while a_sha1 element, which
looks like this:
<a href=""> </a>
It has a firstChild which is a text node containing only whitespace
(single space character) in other web browsers (Firefox 3.5, Opera 10,
Google Chrome 3.0), IE8 clobbers DOM, removing trailing/leading
whitespace.
Protect against this bug by creating text element if it does not
exist.
Found-by: Stephen Boyd <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Stephen Boyd [Thu, 19 Nov 2009 19:44:46 +0000 (11:44 -0800)]
gitweb.js: fix null object exception in initials calculation
Currently handleLine() assumes that a commit author name will always
start with a capital letter. It's possible that the author name is
user@example.com and therefore calling a match() on the name will fail
to return any matches. Subsequently joining these matches will cause an
exception. Fix by checking that we have a match before trying to join
the results into a set of initials for the author.
Signed-off-by: Stephen Boyd <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 13 Nov 2009 01:02:14 +0000 (02:02 +0100)]
gitweb: Make 'history' view (re)use git_log_generic()
Make git_history use git_log_generic, passing git_history_body as one
of its paramaters. This required changes to git_log_generic, in
particular passing more things as parameters.
While refactoring common code of 'log', 'shortlog' and 'history' view,
we did unify pagination, using always the form used by 'history' view,
namely
first * prev * next
in place of
HEAD * prev * next
used by 'log' and 'shortlog' views.
The 'history' view now supports commit limiting via 'hpb' parameter,
similarly to 'shortlog' (and 'log') view. Performance of 'history'
view got improved a bit, as it doesn't run git_get_hash_by_path for
"current" version in a loop. Error detection and reporting for
'history' view changed a bit.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 13 Nov 2009 01:02:13 +0000 (02:02 +0100)]
gitweb: Refactor common parts of 'log' and 'shortlog' views
Put the common parts of git_log and git_shortlog into git_log_generic
subroutine: git_log and git_shortlog are now thin wrappers calling
git_log_generic with appropriate arguments.
The unification of code responsible for 'log' and 'shorlog' actions
lead to the following changes in gitweb output
* 'tree' link in page_nav now uses $hash parameter, as was the case
for 'shortlog' but not for 'log'
* 'log' view now respect $hash_parent limiting, like 'shortlog' did
* 'log' view doesn't have special case for empty list anymore, and it
always uses page_header linking to summary view, like 'shortlog'
did.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Put the main part of 'log' view generation into git_log_body,
similarly how it is done for 'shortlog' and 'history' views (and
also for 'tags' and 'heads' views).
This is preparation for extracting common code between 'log',
'shortlog' and 'history' actions.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Mark Rada [Sat, 7 Nov 2009 15:13:29 +0000 (16:13 +0100)]
gitweb: Smarter snapshot names
Teach gitweb how to produce nicer snapshot names by only using the
short hash id. If clients make requests using a tree-ish that is not
a partial or full SHA-1 hash, then the short hash will also be appended
to whatever they asked for. If clients request snapshot of a tag
(which means that $hash ('h') parameter has 'refs/tags/' prefix),
use only tag name.
Update tests cases in t9502-gitweb-standalone-parse-output.
Gitweb uses the following format for snapshot filenames:
<sanitized project name>-<version info>.<snapshot suffix>
where <sanitized project name> is project name with '.git' or '/.git'
suffix stripped, unless '.git' is the whole project name. For
snapshot prefix it uses:
<sanitized project name>-<version info>/
as compared to <sanitized project name>/ before (without version info).
Current rules for <version info>:
* if 'h' / $hash parameter is SHA-1 or shortened SHA-1, use SHA-1
shortened to to 7 characters
* otherwise if 'h' / $hash parameter is tag name (it begins with
'refs/tags/' prefix, use tag name (with 'refs/tags/' stripped
* otherwise if 'h' / $hash parameter starts with 'refs/heads/' prefix,
strip this prefix, convert '/' into '.', and append shortened SHA-1
after '-', i.e. use <sanitized hash>-<shortened sha1>
Signed-off-by: Mark Rada <redacted> Signed-off-by: Shawn O. Pearce <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Petr Baudis [Fri, 6 Nov 2009 15:08:41 +0000 (16:08 +0100)]
gitweb: Fix blob linenr links in pathinfo mode
In pathinfo mode, we use <base href> that refers to the base location
of gitweb in order for various external media links to work well.
However, this means that for the page to refer to itself, it must
regenerate full link, and this is exactly what the blob view page
did not do for line numbers.
Signed-off-by: Petr Baudis <redacted> Signed-off-by: Junio C Hamano <redacted>
Stephen Boyd [Fri, 16 Oct 2009 04:14:59 +0000 (21:14 -0700)]
gitweb: linkify author/committer names with search
It's nice to search for an author by merely clicking on their name in
gitweb. This is usually faster than selecting the name, copying the
selection, pasting it into the search box, selecting between
author/committer and then hitting enter.
Linkify the avatar icon in log/shortlog view because the icon is directly
adjacent to the name and thus more related. The same is not true
when in commit/tag view where the icon is farther away.
Signed-off-by: Stephen Boyd <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Tue, 13 Oct 2009 19:51:36 +0000 (21:51 +0200)]
gitweb: fix esc_param
The custom CGI escaping done in esc_param failed to escape UTF-8
properly. Fix by using CGI::escape on each sequence of matched
characters instead of sprintf()ing a custom escaping for each byte.
Additionally, the space -> + escape was being escaped due to greedy
matching on the first substitution. Fix by adding space to the
list of characters not handled on the first substitution.
Finally, remove an unnecessary escaping of the + sign.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 9 Oct 2009 12:26:44 +0000 (14:26 +0200)]
gitweb: Do not show 'patch' link for merge commits
The 'patch' view is about generating text/plain patch that can be
given to "git am", and "git am" doesn't understand merges anyway.
Therefore link to 'patch' view should not be shown for merge commits.
Also call to git-format-patch inside the 'patch' action would fail
when 'patch' action is called for a merge commit, with "Reading
git-format-patch failed" text as 'patch' view body.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Mark Rada [Sat, 26 Sep 2009 17:46:08 +0000 (13:46 -0400)]
gitweb: check given hash before trying to create snapshot
Makes things nicer in cases when you hand craft the snapshot URL but
make a typo in defining the hash variable (e.g. netx instead of next);
you will now get an error message instead of a broken tarball.
Tests for t9501 are included to demonstrate added functionality.
Signed-off-by: Mark Rada <redacted> Signed-off-by: Shawn O. Pearce <redacted>
Jakub Narebski [Mon, 7 Sep 2009 12:40:00 +0000 (14:40 +0200)]
gitweb: Add 'show-sizes' feature to show blob sizes in tree view
Add support for 'show-sizes' feature to show (in separate column,
between mode and filename) the size of blobs (files) in the 'tree'
view. It passes '-l' option to "git ls-tree" invocation.
For the 'tree' and 'commit' (submodule) entries, '-' is shown in place
of size; for generated '..' "up directory" entry nothing is shown.
The 'show-sizes' feature is enabled by default.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Tue, 1 Sep 2009 11:39:19 +0000 (13:39 +0200)]
gitweb: Create links leading to 'blame_incremental' using JavaScript
The new 'blame_incremental' view requires JavaScript to run. Not all
web browsers implement JavaScript (e.g. text browsers such as Lynx),
and not all users have JavaScript enabled. Therefore instead of
unconditionally linking to 'blame_incremental' view, we use JavaScript
to convert those links to lead to view utilizing JavaScript, by adding
'js=1' to link.
Currently the only action that takes 'js=1' into account is 'blame',
which then acts as if it was called as 'blame_incremental' action.
Possible enhancement would be to do JavaScript redirect by setting
window.location instead of modifying $format and $action in
git_blame_common() subroutine.
The only JavaScript-aware/using view is currently 'blame_incremental'.
While at it move reading JavaScript to git_footer_html() subroutine.
Note that in this view we do not add 'js=1' currently (even though
perhaps we should; note that for consistency we should also add 'js=1'
in links added by JavaScript part of 'blame_incremental').
This idea was originally implemented by Petr Baudis in
http://article.gmane.org/gmane.comp.version-control.git/47614
but it added <script> element with fixBlameLinks() function in page
header, to be added as onload event using 'onload' attribute of HTML
'body' element: <body onload="fixBlameLinks();">. This version adds
script at then end of page (in the page footer), and uses JavaScript
'window.onload=fixLinks();'. Also in Petr version only links marked
with 'blamelink' class were modified, and they were modified by
replacing "a=blame" by "a=blame_incremental"... which doesn't work for
path_info links, and might replace wrong part if there is "a=blame" in
project name, ref name or file name.
Slightly different solution was implemented by Martin Koegler in
http://thread.gmane.org/gmane.comp.version-control.git/47902/focus=47905
Here GitAddLinks() function was in gitweb.js file, not as contents of
<script> element. It was also included in page header (in <head>
element) though, which means waiting for a script to load (and run).
It was smarter in that to "fix" (modify) link, it split URL, modified
value of 'a' parameter, and then recreated modified link. It avoids
trouble with "a=blame" as substring in project name or file name, but
it doesn't work with path_info URL/link in the way it was written.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Tue, 1 Sep 2009 11:39:17 +0000 (13:39 +0200)]
gitweb: Incremental blame (using JavaScript)
Add 'blame_incremental' view, which uses "git blame --incremental"
and JavaScript (Ajax), where 'blame' use "git blame --porcelain".
* gitweb generates initial info by putting file contents (from
"git cat-file") together with line numbers in blame table
* then gitweb makes web browser JavaScript engine call startBlame()
function from gitweb.js
* startBlame() opens XMLHttpRequest connection to 'blame_data' view,
which in turn calls "git blame --incremental" for a file, and
streams output of git-blame to JavaScript (gitweb.js)
* XMLHttpRequest event handler updates line info in blame view as soon
as it gets data from 'blame_data' (from server), and it also updates
progress info
* when 'blame_data' ends, and gitweb.js finishes updating line info,
it fixes colors to match (as far as possible) ordinary 'blame' view,
and updates information about how long it took to generate page.
Gitweb deals with streamed 'blame_data' server errors by displaying
them in the progress info area (just in case).
The 'blame_incremental' view tries to be equivalent to 'blame' action;
there are however a few differences in output between 'blame' and
'blame_incremental' view:
* 'blame_incremental' always used query form for this part of link(s)
which is generated by JavaScript code. The difference is visible
if we use path_info link (pass some or all arguments in path_info).
Changing this would require implementing something akin to href()
subroutine from gitweb.perl in JavaScript (in gitweb.js).
* 'blame_incremental' always uses "rowspan" attribute, even if
rowspan="1". This simplifies code, and is not visible to user.
* The progress bar and progress info are still there even after
JavaScript part of 'blame_incremental' finishes work.
Note that currently no link generated by gitweb leads to this new view.
This code is based on patch by Petr Baudis <redacted> patch, which
in turn was tweaked up version of Fredrik Kuivinen <redacted>'s
proof of concept patch.
This patch adds GITWEB_JS compile configuration option, and modifies
git-instaweb.sh to take gitweb.js into account. The code for
git-instaweb.sh was taken from Pasky's patch.
Signed-off-by: Fredrik Kuivinen <redacted> Signed-off-by: Petr Baudis <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Tue, 1 Sep 2009 11:39:16 +0000 (13:39 +0200)]
gitweb: Add optional "time to generate page" info in footer
Add "This page took XXX seconds and Y git commands to generate"
to page footer, if global feature 'timed' is enabled (disabled
by default). Requires Time::HiRes installed for high precision
'wallclock' time.
Note that Time::HiRes is being required unconditionally; this is
because setting $t0 variable needs to be done fairly early to have
running time of the whole script. If Time::HiRes module were required
only if 'timed' feature is enabled, the earliest place where starting
time ($t0) could be calculated would be after reading gitweb config,
making "time to generate page" info inaccurate.
This code is based on example code by Petr 'Pasky' Baudis.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Mark Rada [Tue, 25 Aug 2009 04:59:48 +0000 (00:59 -0400)]
gitweb: improve snapshot error handling
The last check in the second block of checks in the &git_snapshot routine
is never executed because the second to last check is a superset of the
last check.
Switch the order of the last two checks. It has the advantage of giving
clients a more specific reason why they cannot get a snapshot format if
the format they have chosen is disabled.
Signed-off-by: Mark Rada <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Sun, 23 Aug 2009 08:28:09 +0000 (10:28 +0200)]
gitweb: pull ref markes pull out of subject <a> element
Since 4afbaef (gitweb: ref markers link to named shortlogs, 2008-09-02),
ref markers that accompany the subject in views such as shortlog and
history point to something different from the subject itself. Therefore,
they should not be included in the same <a> element.
Benefits of the change are:
* better compliance to the XHTML standards, that forbid links within
links even though the restriction cannot be imposed via DTD; this also
benefits visualization in some older browsers;
* when hovering the subject, only the subject itself is underlined; when
hovering the ref markers, only the text in the hovered ref marker is
underlined; previously, hovering any written part of the subject column
led to complete underlying of everything at the same time, with
unpleasing effects.
Signed-off-by: Giuseppe Bilotta <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Benjamin Kramer [Mon, 10 Aug 2009 12:09:00 +0000 (14:09 +0200)]
gitweb: Optimize git-favicon.png
Reduce size of git-favicon.png using a combination of optipng and
pngout. From 164 bytes to 115 bytes (30% reduction). Also reduce
git-logo.png's size by one byte using advcomp.
Signed-off-by: Benjamin Kramer <redacted> Signed-off-by: Junio C Hamano <redacted>
Mark A Rada [Thu, 6 Aug 2009 14:28:25 +0000 (10:28 -0400)]
gitweb: add support for XZ compressed snapshots
The XZ compression format uses the LZMA2 compression algorithm, which
often yields higher compression ratios than both GZip and BZip2 at the
cost of using more CPU time and RAM. XZ is the slowest for compression,
but still much faster than BZip2 for decompression, almost comparable
to GZip (see benchmarks below).
Some simple benchmarks show the pros and cons of using XZ compression;
starting with an already tarball'd archive of the repos listed below.
Memory usage seemed to be consistent for any given algorithm at their
respective default compression levels.
Linux 2.6 series (f5886c7f96f2542382d3a983c5f13e03d7fc5259) 349M
gzip 23.70s user 0.47s system 99% cpu 24.227 total 76M
gunzip 3.74s user 0.74s system 94% cpu 4.741 total
bzip2 130.96s user 0.53s system 99% cpu 2:11.97 total 59M
bunzip2 31.05s user 1.02s system 99% cpu 32.355 total
xz 448.78s user 0.91s system 99% cpu 7:31.28 total 51M
unxz 7.67s user 0.80s system 98% cpu 8.607 total
Git (0a53e9ddeaddad63ad106860237bbf53411d11a7) 11M
gzip 0.77s user 0.03s system 99% cpu 0.792 total 2.5M
gunzip 0.12s user 0.02s system 98% cpu 0.142 total
bzip2 3.42s user 0.02s system 99% cpu 3.454 total 2.1M
bunzip2 0.95s user 0.03s system 99% cpu 0.984 total
xz 12.88s user 0.14s system 98% cpu 13.239 total 1.9M
unxz 0.27s user 0.03s system 99% cpu 0.298 total
XZ (669413bb2db954bbfde3c4542fddbbab53891eb4) 1.8M
gzip 0.12s user 0.00s system 95% cpu 0.132 total 442K
gunzip 0.02s user 0.00s system 97% cpu 0.027 total
bzip2 1.28s user 0.01s system 99% cpu 1.298 total 363K
bunzip2 0.15s user 0.01s system 100% cpu 0.157 total
xz 1.62s user 0.03s system 99% cpu 1.652 total 347K
unxz 0.05s user 0.00s system 99% cpu 0.058 total
From a time and memory perspective, nothing compares to GZip, but if
given an average upload speed of 20KB/s, it would take ~400 seconds
longer to transfer the BZip2'd kernel snapshot than the XZ snapshot;
the transfer time difference is even greater between GZip and XZ. The
real time savings are relatively the same for all test cases, but less
dramatic for smaller repositories.
XZ decompresses ~1.8-2 times slower than GZip, and ~2.7-3.75 times
faster than BZip2; XZ gets relatively faster as snapshots get larger.
However, XZ takes relatively longer to compress as snapshots get larger.
The downside for XZ'd snapshots is the large CPU and memory load put on
the server to generate the compressed snapshot, though XZ will
eventually
have threading support, and the real clock time for making XZ'd
snapshots
would decrease if the server had a beefy multi-core CPU.
XZ compression is disabled by default to allow upgrades to take place
without any surprises, as the CPU and memory requirements will be an
issue for high load or lightweight servers. Also, the XZ format is still
new (format declared stable ~6 months ago), and there have been no
"stable" releases of the utils yet.
Signed-off-by: Mark Rada <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 24 Jul 2009 22:44:06 +0000 (00:44 +0200)]
gitweb: Use light/dark for class names also in 'blame' view
Instead of using "light2" and "dark2" for class names in 'blame' view
(in place of "light" and "dark" classes in other places) to avoid
changing style on hover in 'blame' view while doing it for other views
(like 'shortlog'), use more advanced CSS, relying on the fact that
more specific selector wins.
While at it add a few comments to gitweb CSS file, and consolidate
some repeated info.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 24 Jul 2009 22:44:05 +0000 (00:44 +0200)]
gitweb: Add author initials in 'blame' view, a la "git gui blame"
For example for "Junio C Hamano" initials would be "JH". Of course
initials are added (below shortened SHA-1 of blamed commit) only if
group of lines that blame the same commit has 2 or more lines in it.
Initials are extracted using i18n /\b([[:upper:]])\B/g regexp.
Additionally initials help to distinguish boundary commits, as they
use bold weight font too (in addition to shortened SHA-1 of commit).
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 24 Jul 2009 22:44:04 +0000 (00:44 +0200)]
gitweb: Mark commits with no "previous" in 'blame' view
Use "no-previous" class to mark blamed commits which do not have
"previous" header. Those are commits in which blamed file was created
(added); this includes boundary commits. This means that 'linenr'
link leads to blamed commit, not (one of) parent of blamed commit.
Therefore currently line number for such commit uses bold weight font
to denote this situation; the effect is subtle.
Use "multiple-previous" class in the opposite situation, where blamed
commit has multiple "previous" headers (is an evil merge). Currently
this class is not used for styling. In this situation 'linenr' link
leads to first of "previous" commits (first parent).
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 24 Jul 2009 22:44:03 +0000 (00:44 +0200)]
gitweb: Use "previous" header of git-blame -p in 'blame' view
Luben Tuikov changed 'lineno' link (line number link) from pointing to
'blame' view at given line at blamed commit, to the one at parent of
blamed commit in 244a70e (Blame "linenr" link jumps to previous state at
"orig_lineno", 2007-01-04).
This made it possible to do data mining using 'blame' view, by going
through history of a line using mentioned line number link.
Original implementation called "git rev-parse <commit>^" to find SHA-1
of a parent of a given commit once per each blamed line. In 39c19ce (gitweb: cache $parent_commit info in git_blame(),
2008-12-11)
this was improved so rev-parse was called once per each unique commit
in git-blame output. Alternate solution would be to relax validation
for 'hb' parameter by allowing extended SHA-1 syntax of the form
<rev>^ (perhaps redirecting to gitweb URL with <rev>^ resolved, in
practice moving call to rev-parse to 'the other side of link').
This solution had a bug that it didn't work for boundary commits.
Boundary commits don't have parents, so "git rev-parse <commit>^"
returned literal "<commit>^" (which didn't exists). Gitweb didn't
detect this situation and passed this result literally as 'hb'
parameter in 'linenr' link. Following such link currently gives
400 - Invalid hash base parameter
error; 'hb' parameter is restricted via validate_refname to correct
refnames and doesn't allow for extended SHA-1 syntax. This bug could
have been fixed alternatively by checking if commit is boundary commit,
or check if rev-parse result is unchanged (still ends in '^' prefix).
The solution employing rev-parse to find parent of commit had inherent
problem if blamed commit renamed file; then name of file would be
different in its parent. Solving this outside git-blame would be
difficult and costly (at least cost of additional fork for extra git
command).
Currently gitweb uses information in "previous" header, which was
introduced by Junio C Hamano in 96e1170 (blame: show "previous" information in
--porcelain/--incremental format, 2008-06-04)
This (currently undocumented) header has the following format:
"previous <sha1 of parent commit> <filename at parent>"
Using "previous" header solves both problem of performance and the
problem that blamed commit could have renaming blamed file.
Because "previous" header can be repeated for the same commit when
blamed commit is merge (has more than one parent), and we are
interested usually in _first_ parent, currently we store only first
value if blame header repeats. Using first parent (first "previous"
line) was what gitweb did before; without this change gitweb would use
last parent instead.
If there is no previous commit 'linenr' link points to blamed commit
and blamed filename, making it work correctly for boundary commits.
Acked-by: Luben Tuikov <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 24 Jul 2009 22:44:02 +0000 (00:44 +0200)]
gitweb: Mark boundary commits in 'blame' view
Use "boundary" class to mark boundary commits, which currently results
in using bold weight font for SHA-1 of a commit (to be more exact for
all text in the first cell in row, that contains SHA-1 of a commit).
Detecting boundary commits is done by watching for "boundary" header
in "git blame -p" output. Because this header doesn't carry
additional data the regular expression for blame header fields
had to be slightly adjusted.
With current gitweb API only root (parentless) commits can be boundary
commits.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 24 Jul 2009 22:44:01 +0000 (00:44 +0200)]
gitweb: Make .error style generic
Style for td.error was introduced in 1f1ab5f (gitweb: style done with
stylesheet, 2006-06-20) to replace inline style for errors in old
multi-column "git annotate" based 'blame' view. This view was then
since removed (replaced by "git-blame" based 'blame' view, with fewer
colums), making this style unused.
Make this style more generic by replacing td.error with .error to make
it apply to any element. It will be used in 'blame_incremental' view
to show error messages.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
git-scm.com is now the "official" Git project page, having taken over
from git.or.cz, so update the default link accordingly. This saves a
redirect when people hit git.or.cz.
Signed-off-by: Wincent Colaiuta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 29 Jun 2009 22:00:52 +0000 (00:00 +0200)]
gitweb: gravatar url cache
Views which contain many occurrences of the same email address (e.g.
shortlog view) benefit from not having to recalculate the MD5 of the
email address every time.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 29 Jun 2009 22:00:51 +0000 (00:00 +0200)]
gitweb: (gr)avatar support
Introduce avatar support: the feature adds the appropriate img tag next
to author and committer in commit(diff), history, shortlog, log and tag
views. Multiple avatar providers are possible, but only gravatar is
implemented at the moment.
Gravatar support depends on Digest::MD5, which is a core package since
Perl 5.8. If gravatars are activated but Digest::MD5 cannot be found,
the feature will be automatically disabled.
No avatar provider is selected by default, except in the t9500 test.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 29 Jun 2009 22:00:50 +0000 (00:00 +0200)]
gitweb: use git_print_authorship_rows in 'tag' view too
parse_tag must be adapted to use the hash keys expected by
git_print_authorship_rows. This is not a problem since git_tag is the
only user of this sub.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Sat, 27 Jun 2009 16:24:11 +0000 (18:24 +0200)]
gitweb/README: fix AliasMatch in example
When combining "dumb client" and human-friendly access by using the
'.git' extension to switch between the two, make sure the AliasMatch
covers the entire request. Without a full match, a request for
Jakub Narebski [Fri, 22 May 2009 15:35:46 +0000 (17:35 +0200)]
gitweb: Sanitize title attribute in format_subject_html
Replace control characters with question mark '?' (like in
chop_and_esc_str).
A little background: some web browsers turn on strict (and
unforgiving) XML validating mode for XHTML documents served using
application/xhtml+xml content type. This means among others that
control characters are forbidden to appear in gitweb output.
CGI.pm does by default slight escaping (using simple_escape subroutine
from CGI::Util) of all _attribute_ values (depending on the value of
autoEscape, by default on). This escaping, at least in CGI.pm version
3.10 (most current version at CPAN is 3.43), is minimal: only '"',
'&', '<' and '>' are escaped using named HTML entity references
(", &, < and > respectively). But simple_escape does
not do escaping of control characters such as ^X which are invalid in
XHTML (in strict mode).
If by some accident commit message do contain some control character
in first 50 characters (more or less) of first line of commit message,
and this line is longer than 50 characters (so gitweb shortens it for
display), then gitweb would put this control character in title
attribute (and CGI.pm would not remove them). The tag _contents_ is
safe because it is escaped using esc_html() explicitly, and it
replaces control characters by their printable representation.
While at it: chop_and_escape_str doesn't need capturing group.
Noticed-by: Paul Gortmaker <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Mon, 11 May 2009 17:45:11 +0000 (19:45 +0200)]
gitweb: Remove unused $hash_base parameter from normalize_link_target
...since it was decided for normalize_link_target to only mangle
pathname, and do not try to check if target is present in $hash_base
tree, for performance reasons.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Mon, 11 May 2009 17:42:47 +0000 (19:42 +0200)]
gitweb: Simplify snapshot format detection logic in evaluate_path_info
This issue was caught by perlcritic in harsh severity level noticing
that catch variable was used outside conditional thanks to the
Perl::Critic::Policy::RegularExpressions::ProhibitCaptureWithoutTest
policy. See "Perl Best Practices", chapter 12. Regular Expressions,
section 12.15. Captured Values:
Pattern matches that fail never assign anything to $1, $2, etc.,
nor do they leave those variables undefined. After an unsuccessful
pattern match, the numeric capture variables remain exactly as they
were before the match was attempted.
New version is in my opinion much easier to understand; previous
version worked correctly due to the fact that we returned from loop
on first found match.
Signed-off-by: Jakub Narebski <redacted> Acked-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Sun, 10 May 2009 00:40:37 +0000 (02:40 +0200)]
gitweb: Use block form of map/grep in a few cases more
Use block form of 'grep' i.e. 'grep {BLOCK} LIST' rather than
'grep(EXPR, LIST)' in filter_snapshot_fmts subroutine. This makes
code more readable, as expression is rather long, and statement above
there is 'map' with very similar expression also in the block form.
Remove unnecessary and misleading parentheses around block form 'map'
arguments in quote_command subroutine.
The inner "map" in format_snapshot_links was left alone, as it is not
clear whether adding parentheses or changing it into block form would
improve readibility and clarity of this code.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Sun, 10 May 2009 00:38:34 +0000 (02:38 +0200)]
gitweb: Always use three argument form of open
In most cases (except insert_file() subroutine) we used old two argument
form of 'open' to open files for reading. This can cause subtle bugs when
$projectroot or $projects_list file starts with mode characters ('>', '<',
'+<', '|', etc.) or with leading whitespace; and also when $projects_list
file or $mimetypes_file or ctags files end with trailing whitespace or '|'.
Additionally it is also more clear to explicitly state that we open those
files for reading.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Mon, 11 May 2009 01:21:06 +0000 (03:21 +0200)]
gitweb: Do not use bareword filehandles
gitweb: Do not use bareword filehandles
The script was using bareword filehandles. This is considered a bad
practice so they have been changed to indirect filehandles.
Changes touch git_get_project_ctags and mimetype_guess_file;
while at it rename local variable from $mime to $mimetype (in
mimetype_guess_file) to better reflect its value (its contents).
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Thu, 7 May 2009 17:11:29 +0000 (19:11 +0200)]
gitweb: Remove function prototypes (cleanup)
Use of function prototypes is considered bad practice in Perl. The
ones used here didn't accomplish anything anyhow, so they've been
removed.
>From perlsub(1):
[...] the intent of this feature [prototypes] is primarily to let
you define subroutines that work like built-in functions [...]
you can generate new syntax with it [...]
We don't want to have subroutines behaving exactly like built-in
functions, we don't want to define new syntax / syntactic sugar, so
prototypes in gitweb are not needed... and they can have unintended
consequences.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Holger Weiß [Tue, 31 Mar 2009 16:16:36 +0000 (18:16 +0200)]
gitweb: Fix snapshots requested via PATH_INFO
Fix the detection of the requested snapshot format, which failed for
PATH_INFO URLs since the references to the hashes which describe the
supported snapshot formats weren't dereferenced appropriately.
Signed-off-by: Holger Weiß <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Marcel M. Cary [Wed, 18 Feb 2009 03:00:43 +0000 (19:00 -0800)]
gitweb: Hyperlink multiple git hashes on the same commit message line
The current implementation only hyperlinks the first hash on
a given line of the commit message. It seems sensible to
highlight all of them if there are multiple, and it seems
plausible that there would be multiple even with a tidy line
length limit, because they can be abbreviated as short as 8
characters.
Benchmark:
I wanted to make sure that using the 'e' switch to the Perl regex
wasn't going to kill performance, since this is called once per commit
message line displayed.
In all three A/B scenarios I tried, the A and B yielded the same
results within 2%, where A is the version of code before this patch
and B is the version after.
1: View a commit message containing the last 1000 commit hashes
2: View a commit message containing 1000 lines of 40 dots to avoid
hyperlinking at the same message length
3: View a short merge commit message with a few lines of text and
no hashes
All were run in CGI mode on my sub-production hardware on a recent
clone of git.git. Numbers are the average of 10 reqests per second
with the first request discarded, since I expect this change to affect
primarily CPU usage. Measured with ApacheBench.
Note that the web page rendered was the same; while the new code
supports multiple hashes per line, there was at most one per line.
The primary purpose of scenarios 2 and 3 were to verify that the
addition of 1000 commit messages had an impact on how much of the time
was spent rendering commit messages. They were all within 2% of 0.80
requests per second (much faster).
So I think the patch has no noticeable effect on performance.
Signed-off-by: Marcel M. Cary <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Marcel M. Cary [Wed, 18 Feb 2009 13:09:41 +0000 (14:09 +0100)]
gitweb: Fix warnings with override permitted but no repo override
When a feature like "blame" is permitted to be overridden in the
repository configuration but it is not actually set in the repository,
a warning is emitted due to the undefined value of the repository
configuration, even though it's a perfectly normal condition.
Emitting warning is grounds for test failure in the gitweb test
script.
This error was caused by rewrite of git_get_project_config from using
"git config [<type>] <name>" for each individual configuration
variable checked to parsing "git config --list --null" output in
commit b201927 (gitweb: Read repo config using 'git config -z -l').
Earlier version of git_get_project_config was returning empty string
if variable do not exist in config; newer version is meant to return
undef in this case, therefore change in feature_bool was needed.
Additionally config_to_* subroutines were meant to be invoked only if
configuration variable exists; therefore we added early return to
git_get_project_config: it now returns no value if variable does not
exists in config. Otherwise config_to_* subroutines (config_to_bool
in paryicular) wouldn't be able to distinguish between the case where
variable does not exist and the case where variable doesn't have value
(the "[section] noval" case, which evaluates to true for boolean).
While at it fix bug in config_to_bool, where checking if $val is
defined (if config variable has value) was done _after_ stripping
leading and trailing whitespace, which lead to 'Use of uninitialized
value' warning.
Add test case for features overridable but not overriden in repo
config, and case for no value boolean configuration variable.
Signed-off-by: Marcel M. Cary <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Sun, 15 Feb 2009 09:18:36 +0000 (10:18 +0100)]
gitweb: fix wrong base URL when non-root DirectoryIndex
CGI::url() has some issues when rebuilding the script URL if the script
is a DirectoryIndex.
One of these issue is the inability to strip PATH_INFO, which is why
we had to do it ourselves.
Another issue is that the resulting URL cannot be used for the <base>
tag: it works if we're the DirectoryIndex at the root level, but not
otherwise.
We fix this by building the proper base URL ourselves, and improve the
comment about the need to strip PATH_INFO manually while we're at it.
Additionally t/t9500-gitweb-standalone-no-errors.sh had to be modified
to set SCRIPT_NAME variable (CGI standard states that it MUST be set,
and now gitweb uses it if PATH_INFO is not empty, as is the case for
some of tests in t9500).
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Matt McCutchen [Sun, 8 Feb 2009 00:00:09 +0000 (19:00 -0500)]
gitweb: add $prevent_xss option to prevent XSS by repository content
Add a gitweb configuration variable $prevent_xss that disables features
to prevent content in repositories from launching cross-site scripting
(XSS) attacks in the gitweb domain. Currently, this option makes gitweb
ignore README.html (a better solution may be worked out in the future)
and serve a blob_plain file of an untrusted type with
"Content-Disposition: attachment", which tells the browser not to show
the file at its original URL.
The XSS prevention is currently off by default.
Signed-off-by: Matt McCutchen <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Fri, 6 Feb 2009 09:12:41 +0000 (10:12 +0100)]
gitweb: Better regexp for SHA-1 committag match
Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
to match word boundary at the beginning and the end. This way we
reduce number of false matches, for example we now don't match
0x74a5cd01 which is hex decimal (for example memory address),
but is not SHA-1.
Suggested-by: Johannes Schindelin <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Sun, 1 Feb 2009 21:37:45 +0000 (22:37 +0100)]
gitweb: Update README that gitweb works better with PATH_INFO
One had to configure gitweb for it to find static files (stylesheets,
images) when using path_info URLs. Now that it is not necessary
thanks to adding BASE element to HTML head if needed, update README to
reflect this fact.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Sat, 31 Jan 2009 01:31:50 +0000 (02:31 +0100)]
gitweb: make static files accessible with PATH_INFO
Gitweb links to a number of static files such as CSS stylesheets,
favicon or the git logo. When, such as with the default Makefile, the
paths to these files are relative (i.e. doesn't start with a "/"), the
files become inaccessible in any view other tha project list and summary
page if gitweb is invoked with a non-empty PATH_INFO.
Fix this by adding a <base> element pointing to the script's own URL,
which ensure that all relative paths will be resolved correctly.
Signed-off-by: Giuseppe Bilotta <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 26 Jan 2009 11:50:16 +0000 (12:50 +0100)]
gitweb: check if-modified-since for feeds
Offering Last-modified header for feeds is only half the work, even if
we bail out early on HEAD requests. We should also check that same date
against If-modified-since, and bail out early with 304 Not Modified if
that's the case.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 26 Jan 2009 11:50:15 +0000 (12:50 +0100)]
gitweb: last-modified time should be commiter, not author
The last-modified time header added by RSS to increase cache hits from
readers should be set to the date the repository was last modified. The
author time in this respect is not a good guess because the last commit
might come from a oldish patch.
Use the committer time for the last-modified header to ensure a more
correct guess of the last time the repository was modified.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 26 Jan 2009 11:50:14 +0000 (12:50 +0100)]
gitweb: rss channel date
The RSS 2.0 specifications defines not one but _two_ dates for its
channel element! Woohoo! Luckily, it seems that consensus seems to be
that if both are present they should be equal, except for some very
obscure and discouraged cases. Since lastBuildDate would make more sense
for us and pubDate seems to be the most commonly used, we defined both
and make them equal.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 26 Jan 2009 11:50:13 +0000 (12:50 +0100)]
gitweb: rss feed managingEditor
The RSS 2.0 specification allows an optional managingEditor tag for the
channel, containing the "email address for person responsible for editorial
content", which is basically the project owner.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 26 Jan 2009 11:50:12 +0000 (12:50 +0100)]
gitweb: feed generator metadata
Add <generator> tag to RSS and Atom feed. Versioning info (gitweb/git
core versions, separated by a literal slash) is stored in the
appropriate attribute for the Atom feed, and in the tag content for the
RSS feed.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Mon, 26 Jan 2009 11:50:11 +0000 (12:50 +0100)]
gitweb: channel image in rss feed
Define the channel image for the rss feed when the logo or favicon are
defined, preferring the former to the latter. As suggested in the RSS
2.0 specifications, the image's title and link as set to the same as the
channel's.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
With PATH_INFO urls, actions for the projects list (e.g. opml,
project_index) were being put in the URL right after the base. The
resulting URL is not properly parsed by gitweb itself, since it expects
a project name as first component of the URL.
Accepting global actions in use_pathinfo is not a very robust solution
due to possible present and future conflicts between project names and
global actions, therefore we just refuse to create PATH_INFO URLs when
the project is not defined.
Signed-off-by: Giuseppe Bilotta <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Since the OPML project list view was hand-coding the RSS and HTML URLs,
it didn't respect global options such as use_pathinfo. Make it use
href() to ensure consistency with the rest of the gitweb setup.
Signed-off-by: Giuseppe Bilotta <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Devin Doucette [Sat, 27 Dec 2008 09:39:31 +0000 (02:39 -0700)]
gitweb: Fix export check in git_get_projects_list
When $filter was empty, the path passed to check_export_ok would
contain an extra '/', which some implementations of export_auth_hook
are sensitive to.
It makes more sense to fix this here than to handle the special case
in each implementation of export_auth_hook.
Signed-off-by: Devin Doucette <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Thu, 18 Dec 2008 07:13:18 +0000 (08:13 +0100)]
gitweb: add patches view
The only difference between patch and patches view is in the treatement
of single commits: the former only displays a single patch, whereas the
latter displays a patchset leading to the specified commit.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Giuseppe Bilotta [Thu, 18 Dec 2008 07:13:17 +0000 (08:13 +0100)]
gitweb: change call pattern for git_commitdiff
Since we are going to introduce an additional parameter for
git_commitdiff to tune patch view, we switch to named/hash-based
parameter passing for clarity and robustness.
Giuseppe Bilotta [Thu, 18 Dec 2008 07:13:16 +0000 (08:13 +0100)]
gitweb: add patch view
The output of commitdiff_plain is not intended for git-am:
* when given a range of commits, commitdiff_plain publishes a single
patch with the message from the first commit, instead of a patchset
* the hand-built email format replicates the commit summary both as
email subject and as first line of the email itself, resulting in
a duplication if the output is used with git-am.
We thus create a new view that can be fed to git-am directly, allowing
patch exchange via gitweb. The new view exposes the output of git
format-patch directly, limiting it to a single patch in the case of a
single commit.
A configurable upper limit defaulting to 16 is imposed on the number of
commits which will be included in a patchset, to prevent DoS attacks on
the server. Setting the limit to 0 will disable the patch view, setting
it to a negative number will remove the limit.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Wed, 17 Dec 2008 03:42:02 +0000 (19:42 -0800)]
gitweb: do not run "git diff" that is Porcelain
Jakub says that legacy-style URI to view two blob differences are never
generated since 1.4.3. This codepath runs "git diff" Porcelain from the
gitweb, which is a no-no.
Jakub Narebski [Thu, 11 Dec 2008 00:33:29 +0000 (01:33 +0100)]
gitweb: cache $parent_commit info in git_blame()
Luben Tuikov changed 'lineno' link from leading to commit which gave
current version of given block of lines, to leading to parent of this
commit in 244a70e (Blame "linenr" link jumps to previous state at
"orig_lineno"). This made possible data mining using 'blame' view.
The current implementation calls rev-parse once per each blamed line
to find parent revision of blamed commit, even when the same commit
appears more than once, which is inefficient.
This patch mitigates this issue by caching $parent_commit info in
%metainfo, which makes gitweb call rev-parse only once per each
unique commit in the output from "git blame".
In the tables below you can see simple benchmark comparing gitweb
performance before and after this patch
As you can see the greater ratio of lines in file to unique commits
in blame output, the greater gain from the new implementation.
Legend:
[1] Number of lines:
$ wc -l <file>
[2] Number of unique commits in the blame output:
$ git blame -p <file> | grep author-time | wc -l
[3] Time for running "git blame -p" (user time, single run):
$ time git blame -p <file> >/dev/null
[4] Time to run gitweb as Perl script from command line:
$ gitweb-run.sh "p=.git;a=blame;f=<file>" > /dev/null 2>&1
The gitweb-run.sh script includes slightly modified (with adjusted
pathnames) code from gitweb_run() function from the test script
t/t9500-gitweb-standalone-no-errors.sh; gitweb config file
gitweb_config.perl contents (again up to adjusting pathnames; in
particular $projectroot variable should point to top directory of git
repository) can be found in the same place.
Discussion
~~~~~~~~~~
A possible future improvement would be to open a bidi pipe to
"git cat-file --batch-check", (like in Git::Repo in gitweb caching by
Lea Wiemann), feed $long_rev^ to it, and parse its output, which is
in the following form:
This would mean one call to git-cat-file for the whole 'blame' view,
instead of one call to git-rev-parse per each unique commit in blame
output.
Yet another solution would be to change use of validate_refname() to
validate_revision() when checking script parameters (CGI query or
path_info), with validate_revision being something like the following:
sub validate_revision {
my $rev = shift;
return validate_refname(strip_rev_suffixes($rev));
}
so we don't need to calculate $long_rev^, but can pass "$long_rev^" as
'hb' parameter.
This solution has the advantage that it can be easily adapted to future
incremental blame output.
Signed-off-by: Jakub Narebski <redacted> Acked-by: Luben Tuikov <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Tue, 9 Dec 2008 22:46:16 +0000 (23:46 +0100)]
gitweb: Move 'lineno' id from link to row element in git_blame
Move l<line number> ID from <a> link element inside table row (inside
cell element for column with line numbers), to encompassing <tr> table
row element. It was done to make it easier to manipulate result HTML
with DOM, and to be able write 'blame_incremental' view with the same,
or nearly the same result.
Signed-off-by: Jakub Narebski <redacted> Acked-by: Luben Tuikov <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Mon, 8 Dec 2008 13:13:21 +0000 (14:13 +0100)]
gitweb: Fix bug in insert_file() subroutine
In insert_file() subroutine (which is used to insert HTML fragments as
custom header, footer, hometext (for projects list view), and per
project README.html (for summary view)) we used:
map(to_utf8, <$fd>);
This doesn't work, and other form has to be used:
map { to_utf8($_) } <$fd>;
Now with test for t9600 added, for $GIT_DIR/README.html.
Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Jakub Narebski [Mon, 1 Dec 2008 18:01:42 +0000 (19:01 +0100)]
gitweb: Fix handling of non-ASCII characters in inserted HTML files
Use new insert_file() subroutine to insert HTML chunks from external
files: $site_header, $home_text (by default indextext.html),
$site_footer, and $projectroot/$project/REAME.html.
All non-ASCII chars of those files will be broken by Perl IO layer
without decoding to utf8, so insert_file() does to_utf8() on each
printed line; alternate solution would be to open those files with
"binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
Note that inserting README.html lost one of checks for simplicity.
Noticed-by: Tatsuki Sugiura <redacted> Signed-off-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
This is taken from a patch from Giuseppe but unfortunately it came
too late to replace the series that was already on "next". The comment
he updated here is better than the version we had previously, so I am
cherry-picking this bit not to lose it.
Giuseppe Bilotta [Sat, 29 Nov 2008 21:07:29 +0000 (13:07 -0800)]
gitweb: make gitweb_check_feature a boolean wrapper
The gitweb_get_feature() function retrieves the configuration parameters
for the feature (such as the list of snapshot formats or the list of
additional actions), but it is very often used to see if feature is
enabled (which is returned as the first element in the list).
Because accepting the returned list in the scalar context by mistake
yields the number of elements in the array, which is non-zero in all
cases, such a mistake would result in a bug for the latter use, with
disabled features appearing enabled. All existing callers that call the
function for this purpose assign the return value in the list context to
retrieve the first element, but that is only because we fixed careless
callers recently.
This adds gitweb_check_feature() as a wrapper to gitweb_get_feature() that
can be called safely in the scalar context to see if a feature is enabled
to reduce the risk of future bugs. Callers of "get" that use the call
only to see if the feature is enabled are updated to call this wrapper.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Sat, 29 Nov 2008 21:02:08 +0000 (13:02 -0800)]
gitweb: rename gitweb_check_feature to gitweb_get_feature
The function is about retrieving the configuration parameter list for the
feature. A more robust way to check if a feature is enabled will be
introduced in the next patch, and the function will be called
gitweb_check_feature.
Junio C Hamano [Sat, 29 Nov 2008 20:53:41 +0000 (12:53 -0800)]
gitweb: fix 'ctags' feature check and others
gitweb_check_feature() function is to retrieve the configuration parameter
list and calling it in the scalar context does not give its first element
that tells if the feature is enabled. This fixes all the existing callers
to call the function correctly in the list context.
ModPerl::Registry precompiles scripts by wrapping them
in a subroutine. This causes ordinary subroutines of the
script to become nested, and warnings appear:
gitweb.cgi: Variable "$path_info" will not stay shared
This warning means that $path_info was declared as 'my',
and thus according to the perl evaluation rules all nested
subroutines will retain a reference to the instance of the
variable used in the first invocation of the master script.
When the script (i.e. the master meta-subroutine) is executed
the second time, it will use a new instance, so the logic
breaks. To avoid this it is necessary to declare all global
variables as 'our', which places them at the package level.
Signed-off-by: Alexander Gavrilov <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
Add a configuration variable that can be used to specify an
arbitrary subroutine that will be called in the same situations
where $export_ok is checked, and its return value used
to decide whether the repository is to be shown.
This allows the user to implement custom authentication
schemes, for example by issuing a subrequest through mod_perl
and checking if Apache will authorize it.
Signed-off-by: Alexander Gavrilov <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
gitweb: Use single implementation of export_ok check.
GitWeb source contains a special function that implements the
export_ok check, but validate_project still uses a separate copy
of essentially the same code.
This patch makes it use the dedicated function, thus ensuring
that all checks are done through a single code path.
Signed-off-by: Alexander Gavrilov <redacted> Acked-by: Jakub Narebski <redacted> Signed-off-by: Junio C Hamano <redacted>
gitweb: embed snapshot format parameter in PATH_INFO
When PATH_INFO is active, get rid of the sf CGI parameter by embedding
the snapshot format information in the PATH_INFO URL, in the form of an
appropriate extension.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
We parse requests for $project/snapshot/$head.$sfx as equivalent to
$project/snapshot/$head?sf=$sfx, where $sfx is any of the known
(although not necessarily supported) snapshot formats (or its default
suffix).
The filename for the resulting package preserves the requested
extensions (so asking for a .tgz gives a .tgz, and asking for a .tar.gz
gives a .tar.gz), although for obvious reasons it doesn't preserve the
basename (git/snapshot/next.tgz returns a file names git-next.tgz).
This introduces a potential case for ambiguity if a project has a head
that ends with a snapshot-like suffix (.zip, .tgz, .tar.gz, etc) and the
sf CGI parameter is not present; however, gitweb only produces URLs with
the sf parameter currently, so this is only a potential issue for
hand-coded URLs for extremely unusual project.
Signed-off-by: Giuseppe Bilotta <redacted> Signed-off-by: Junio C Hamano <redacted>
Lady’s Gitweb / Gitweb / log