* jn/gitweb-cleanup:
gitweb: Remove unused $hash_base parameter from normalize_link_target
gitweb: Simplify snapshot format detection logic in evaluate_path_info
gitweb: Use capturing parentheses only when you intend to capture
gitweb: Replace wrongly added tabs with spaces
gitweb: Use block form of map/grep in a few cases more
gitweb: Always use three argument form of open
gitweb: Always use three argument form of open
gitweb: Do not use bareword filehandles
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 <paul.gortmaker@windriver.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
...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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jnareb@gmail.com>
Acked-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-capturing groups are useful because they have better runtime
performance and do not copy strings to the magic global capture
variables.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In two places there was hard tab character instead of space.
Fix this.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
From 94638fb6edf3ea693228c680a6a30271ccd77522 Mon Sep 17 00:00:00 2001
From: Jakub Narebski <jnareb@gmail.com>
Date: Mon, 11 May 2009 03:25:55 +0200
Subject: [PATCH] gitweb: Localize magic variable $/
Instead of undefining and then restoring magic variable $/ (input
record separator) for 'slurp mode', localize it.
While at it, state explicitely that "local $/;" makes it undefined, by
using explicit "local $/ = undef;".
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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ß <holger@zedat.fu-berlin.de>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <marcel@oak.homeunix.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <marcel@oak.homeunix.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <Johannes.Schindelin@gmx.de>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suggest opml.xml as name for OPML view by providing the appropriate
header, consistently with similar usage in project_index view.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/gitweb-blame:
gitweb: cache $parent_commit info in git_blame()
gitweb: A bit of code cleanup in git_blame()
gitweb: Move 'lineno' id from link to row element in git_blame
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 <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <devin@doucette.cc>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We link to patch view in commit and commitdiff view, and to patches view
in log and shortlog view.
In (short)log view, the link is only offered when the number of commits
shown is no more than the allowed maximum number of patches.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The boolean feature subroutines behaved identically except for the
name of the configuration option, so make that a parameter and unify
them.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
File | L[1] | C[2] || Time0[3] | Before[4] | After[4]
====================================================================
blob.h | 18 | 4 || 0m1.727s | 0m2.545s | 0m2.474s
GIT-VERSION-GEN | 42 | 13 || 0m2.165s | 0m2.448s | 0m2.071s
README | 46 | 6 || 0m1.593s | 0m2.727s | 0m2.242s
revision.c | 1923 | 121 || 0m2.357s | 0m30.365s | 0m7.028s
gitweb/gitweb.perl | 6291 | 428 || 0m8.080s | 1m37.244s | 0m20.627s
File | L/C | Before/After
=========================================
blob.h | 4.5 | 1.03
GIT-VERSION-GEN | 3.2 | 1.18
README | 7.7 | 1.22
revision.c | 15.9 | 4.32
gitweb/gitweb.perl | 14.7 | 4.71
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:
926b07e694599d86cec668475071b32147c95034 commit 637
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 <jnareb@gmail.com>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Among others, here are the highlights:
* move variable declaration closer to the place it is set and used,
if possible,
* uniquify and simplify coding style a bit, which includes removing
unnecessary '()'.
* check type only if $hash was defined, as otherwise from the way
git_get_hash_by_path() is called (and works), we know that it is
a blob,
* use modern calling convention for git-blame,
* remove unused variable,
* don't use implicit variables ($_),
* add some comments
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jnareb@gmail.com>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
GIT 1.6.0.5
"git diff <tree>{3,}": do not reverse order of arguments
tag: delete TAG_EDITMSG only on successful tag
gitweb: Make project specific override for 'grep' feature work
http.c: use 'git_config_string' to get 'curl_http_proxy'
fetch-pack: Avoid memcpy() with src==dst
The 'grep' feature was marked in the comments as having project
specific config, but it lacked 'sub' key required for it to work.
Kind-of-Noticed-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <sugi@nemui.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gb/gitweb-snapshot-pathinfo:
gitweb: embed snapshot format parameter in PATH_INFO
gitweb: retrieve snapshot format from PATH_INFO
gitweb: make the supported snapshot formats array global
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 <angavrilov@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <angavrilov@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <angavrilov@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The array of supported snapshot format is used and defined (with two
different names) in two routines, one of which (format_snapshot_links)
is often called multiple times per page.
Simplify code and speed up page generation by making the array global.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes it possible to use an URL such as
project/action/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
project/action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent (e.g. 'shortlog') can now get all of their parameters
from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Generate PATH_INFO URLs in the form project/action/hash_base:/filename
rather than project/action/hash_base:filename (the latter form is still
accepted in input).
This minimal change allows relative navigation to work properly when
viewing HTML files in raw ('blob_plain') mode.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
$project/$branch[:$filename], except when it was used to access a branch
whose name matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The projectroot path could have SP in it, in which case iterating over
<$git_dir/ctags/*> does not correctly enumerate the cloud tags files at
all.
This can be observed by creating an empty t/trash directory and running
t9500 test. The $projectroot ends with "trash directory.t9500-gitweb-/"
and <$glob> would give "trash", which can be opened and reading from it
immediately yields undef, which in turn gives an undef value warning to
the standard error stream upon attempt to chomp it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since input parameters can be obtained both from CGI parameters and
PATH_INFO, we would like most of the code to be agnostic about the way
parameters were retrieved. We thus collect all the parameters into the
new %input_params hash, delaying validation after the collection is
completed.
Although the kludge removal is minimal at the moment, it makes life much
easier for future expansions such as more extensive PATH_INFO use or
other form of input such as command-line support.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Make processing format string in custom links in action bar ('actions'
feature) more robust. Now there would be no problems if one of
expanded values (for example project name, of project filename)
contains '%'; additionally format string supports '%' escaping by
doubling, i.e. '%%' expands to '%'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* pb/gitweb-tagcloud:
gitweb: Support for simple project search form
gitweb: Make the by_tag filter delve in forks as well
gitweb: Support for tag clouds
... (+ many updates from master) ...
Conflicts:
gitweb/gitweb.perl
This is a trivial patch adding support for searching projects by name
and description, making use of the "infrastructure" provided by the
tag cloud generation.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This requires us to build a full index including forks and then weed
them out only when printing.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The "Content tags" (nothing to do with usual Git tags!) are free-form
strings that are attached to random projects and displayed in the
well-known Web2.0-ish tag cloud above project list.
The feature will make use of HTML::TagCloud if available, but will
still display (less pretty) list of tags in case the module is not
installed.
The tagging itself is not done by gitweb - user-provided external
helper CGI needs to be provided; one example is the tagproj.cgi
of Girocco. This functionality might get integrated to gitweb
in the future.
The tags are stored one-per-file in ctags/ subdirectory. The reason
they are not stored in the project config file is that you usually
want to give anyone (even CGI scripts) permission to create new tags
and they are non-essential information, and thus you would make
the ctags/ subdirectory world-writable.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This makes it possible to easily extend gitweb with custom functionality,
e.g. git-browser or web-based repository administration system like
the repo.or.cz/Girocco duct tape.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
gitweb: Add path_info tests to t/t9500-gitweb-standalone-no-errors.sh
gitweb: Fix two 'uninitialized value' warnings in git_tree()
Solaris: Use OLD_ICONV to avoid compile warnings
gitweb: remove PATH_INFO from $my_url and $my_uri
If we did try to access nonexistent directory or file, which means
that git_get_hash_by_path() returns `undef`, uninitialized $hash
variable was passed to 'open' call. Now we fail early with "404 Not
Found - No such tree" error. (If we try to access something which
does not resolve to tree-ish, for example a file / 'blob' object, the
error will be caught later, as "404 Not Found - Reading tree failed"
error).
If we tried to use 'tree' action without $file_name ('f' parameter)
set, which means either tree given by hash or a top tree (and we
currently cannot distinguish between those two cases), we cannot print
path breadcrumbs with git_print_page_path(). Fix this by moving call
to git_print_page_path() inside conditional.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In the metadata table of the summary page, all rows have their
id (or class in case of URL) set now. This for example lets sites
easily disable fields they do not want to show in their custom
stylesheet (e.g. they are overly technical or irrelevant for the site).
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch fixes PATH_INFO handling by removing the relevant part from
$my_url and $my_uri, thus making it unnecessary to specify them by hand
in the gitweb configuration.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For the last 30 years, the mankind uses the octal representation of
characters only in rare cases and most character codes are hardly
recognizable in octal. In contrast, many programmers still know
hexadecimal well and that is also the representation of choice e.g.
for Unicode codepoints.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The list of forks on the summary page was unsorted, this just makes
them sorted by age, which seems a fair way to decide which forks are
shown before the list size cut-off (15) kicks in.
s/noheader/no_header was just to make it obvious what the parameter
affects, so all the code can be found with one grep.
pb: As suggested by Mike, I have augmented this by an additional patch
that refactors the sorting logic so that it is not tied to printing
the headers.
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This decouples the sorting of project list and printing the column
headers, so that the project list can be easily sorted even when
the headers are not shown.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If $hash_parent is defined, shortlog now limits the list of commits at
those between $hash_parent (exclusive) and $hash (inclusive).
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
sha1_file: link() returns -1 on failure, not errno
Make git archive respect core.autocrlf when creating zip format archives
Add new test to demonstrate git archive core.autocrlf inconsistency
gitweb: avoid warnings for commits without body
Clarified gitattributes documentation regarding custom hunk header.
git-svn: fix handling of even funkier branch names
git-svn: Always create a new RA when calling do_switch for svn://
git-svn: factor out svnserve test code for later use
diff/diff-files: do not use --cc too aggressively
In the unusual case when there is no commit message, gitweb would
output an uninitialized value warning.
Signed-off-by: Joey Hess <joey@kitenet.net>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch turns ref markers for tags and heads into links to
appropriate views for the ref name, depending on current context.
For annotated tags, we link to the tag view, unless that's the current
view, in which case we switch to shortlog. For other refs, we prefer the
current view if it's history or (short)log, and default to shortlog
otherwise.
Appropriate changes are made in the CSS to prevent ref markers from
being annoyingly blue and underlined, unless hovered. A visual
indication of the target view difference is also implemented by making
annotated tags show up in italic.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many error status codes simply default to 403 Forbidden, which is not
correct in most cases. This patch makes gitweb return semantically
correct status codes.
For convenience the die_error function now only takes the status code
without reason as first parameter (e.g. 404 instead of "404 Not
Found"), and it now defaults to 500 (Internal Server Error), even
though the default is not used anywhere.
Also documented status code conventions in die_error.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The parse_ref method became unused in cd1464083c, but the author
decided to leave it in. Now it gets in the way of refactoring, so
let's remove it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This eliminates the function git_cmd_str, which was used for composing
command lines, and adds a quote_command function, which quotes all of
its arguments (as in quote.c).
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes single point where $GIT (which can contain full path
to git binary) with embedded spaces gave errors.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extract generating table header cell, for tables which can be sorted
by its columns, into print_sort_th_str() and print_sort_th_num()
subroutines, and print_sort_th() driver subroutine.
This avoids repetition, and should make further improvements (like
JavaScript sorting) easier. The subroutine uses now "replay" link,
so it is generic enough to be able to use it for other tables which
can be sorted by column, like for example 'heads' and 'tags' view
(sort by name, or sort by age).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extract filling project list info, i.e. adding age, description, owner
and forks information, into fill_project_list_info() subroutine. This
is preparation for smart pagination and smart searching (to make it
possible to calculate/generate info only for those projects which will
be shown).
Small changes compared to original version to improve readability
(comments, names of variables, named loops).
Additionally, store both full ('descr_long') and shortened ('descr')
project description in Perl's internal form (using to_utf8).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_blame is dead code. It's possible to plug it in place of
git_blame2, but I don't know whether anyone does still that,
because git_blame2 can now be considered stable enough, I think.
Signed-off-by: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier "blob_plain" view sent "charset=utf-8" only when gitweb
guessed the content type to be text by reading from it, and not when
the MIME type was obtained from /etc/mime.types, or when gitweb
couldn't guess mimetype and used $default_blob_plain_mimetype.
This fixes the bug by always add charset info from
$default_text_plain_charset (if it is defined) to "raw" (a=blob_plain)
output for 'text/plain' blobs.
Generating information for Content-Type: header got separated into
blob_contenttype() subroutine; adding charset info in a special case
was removed from blob_mimetype(), which now should return mimetype
only.
While at it cleanup code a bit: put subroutine parameter
initialization first, make error message more robust (when $file_name
is not defined) if more cryptic, remove unnecessary '"' around
variable ("$var" -> $var).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix search form generation to not modify $cgi->param(...)'s.
In git_header_html() we used to use $cgi->hidden(-name => "a") etc. to
generate hidden fields; unfortunately to use this form it is required
to modify $cgi->param("a") etc., which makes href(-replay,...) use
wrong replay values. This for example made the "next" link on the
bottom of the page has a=search instead of a=$action, and thus fails to
get you to the next page.
Because in CGI the value of a hidden field is "sticky", there is no
way to modify it short of modifying $cgi->param(...). Therefore it
got replaced by generating <input type="hidden" ...> element [semi]
directly.
Alternate solution would be for href(-replay,...) to use values saved
in global variables, such as $action etc., instead of (re)reading them
from $cgi->param($symbol).
The bad link was reported by Kai Blin through
http://bugs.debian.org/481902
Reported-by: Kai Blin <kai.blin@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Tested-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was a bug in the implementation of the "next" links in
format_paging_nav (for log and shortlog), which caused the next links
to always be displayed, even if there is no next page. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix chop_str not to cut in middle of utf8 multibyte chars. Without
this fix at least author name in short log may cut in middle of a
multibyte char. When the result comes to esc_html to_utf8 is called
again, which doesn't find valid utf8 and decodes using
$fallback_encoding making it even worse.
This also have the nice side effect that it actually tries to show the
first 10 _characters_, not the number of characters that happened to fit
into 10 bytes.
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Michael G. Noll said in comments to the "Switching my code repository from
Subversion (SVN) to git" article (http://tinyurl.com/37v67l) in his "My
digital moleskine" blog, that one of the things he is missing in gitweb
from SVN::Web is an RSS feed with news/information of the current view
(including RSS feed for single file or directory).
This is not exactly true, as since refactoring feed generation in af6feeb
(gitweb: Refactor feed generation, make output prettier, add Atom feed,
2006-11-19), gitweb can generate feeds (RSS or Atom) for history of a
given branch, history limited to a given directory, or history of a given
file. Nevertheless this required handcrafting the URL to get wanted RSS
feed.
This commit makes gitweb select feed links in the HTML header and in
page footer depending on current view (action). It is more elaborate,
and I guess more correct, than simple patch adding $hash ('h')
parameter to *all* URLs, including feed links, by Jean-Baptiste Quenot
Subject: [PATCH] gitweb: Add hash parameter in feed URL when a hash
is specified in the current request
Message-ID: <ae63f8b50803211138y6355fd11pa64cda50a1f53011@mail.gmail.com>
If $hash ('h') or $hash_base ('hb') parameter is a branch name
(i.e. it starts with 'refs/heads/'; all generated URLs use this form
to discriminate between tags and heads), it is used in feed URLs; if
$file_name ('f') is defined, it is used in feed URLs. Feed title is
set according to the kind of web feed: it is either 'log' for generic
feed, 'log of <branch>', 'history of <filename>' for generic history
(using implicit or explicit HEAD, i.e. current branch) or 'history of
<filename> on <branch>'.
There are special cases: 'heads' and 'forks' views should use OPML
providing list of available feeds; 'tags' probably also should use
OPML; there is no web feed equivalent to 'search' view. Currently all
those cases fallback to (show) default feed. Such feed link uses
"generic" class, and is shown in slightly lighter color for
distinction.
Currently feed can have but one starting point, and does not support
negative (exclude) commit arguments. Therefore for now for *diff
views it is chosen that feed follow the "to" part: to-name, to-commit
for 'blobdiff', 'treediff' and 'commitdiff' views.
Generating parameters for href() for feed link was separated
(refactored) into get_feed_info() subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
post-receive-email: fix accidental removal of a trailing space in signature line
Escape project names before creating pathinfo URLs
Escape project name in regexp
bash: Add completion for git diff --base --ours --theirs
diff-options.txt: document the new "--dirstat" option
If a project name contains special URL characters like +, gitweb's links
break in subtle ways. The solution is to pass the project name through
esc_url() and using the return value.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The project name, when used in a regular expression, needs to be quoted
properly, so that stuff like '++' in the project name does not cause
Perl to barf.
Related info: http://bugs.debian.org/476076
This is a bug in Perl's CGI.pm, but fixing that exposed a similar bug in
gitweb.perl
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
gitweb: Fix 'history' view for deleted files with history
Document that WebDAV doesn't need git on the server, and works over SSL
git-remote: reject adding remotes with invalid names
am: POSIX portability fix
When asked for history of a file which is not present in given branch
("HEAD", i.e. current branch, or given by transient $hash_hase ('hb')
parameter), but is present deeper in the history (meaning that "git
rev-list --full-history $hash_base -- $file_name" is not empty), and
there is no $hash ('h') parameter set for a file, gitweb would spew
multiple of "Use of uninitialized value" warnings, and some links
would be missing. This commit fixes this bug.
This bug occurs in the rare cases when "git log -- <path>" is empty
and "git log --full-history -- <path>" is not, or to be more exact in
the cases when full-history starts later than given branch. It can
happen if you are using handcrafted gitwb URL, or if you follow
generic 'history' link or bookmark for a file which got deleted.
Gitweb tried to get file type ('tree', or 'blob', or even 'commit')
from the commit we start searching from (where the file was not
present), and not among found commits. This was the cause of "Use of
uninitialized value" warnings.
This commit also add tests for such situation to t9500 test.
While we are it, return HTTP error if there is _no_ history; it means
that file or directory was not found (for given branch). Also error
out if type of item could not be found: it should not happen now, but
better be sure.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 6aa6f92fda.
It caused is_deleted() subroutine to output warnings when dealing with
old, legacy gitweb blobdiff URLs without either 'hb' or 'hpb'
parameters.
This fixes http://bugs.debian.org/469083
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
From a distribution point of view, configuration files for applications
should reside in /etc/. On the other hand it's convenient for multiple
instances of gitweb (e.g. virtual web servers on a single machine) to have
a per-instance configuration file, just as gitweb currently supports
through the file gitweb_config.perl next to the cgi.
To support both at runtime, this commit introduces GITWEB_CONFIG_SYSTEM as
a system-wide configuration file which will be used as a fallback if the
config file sprecified throug GITWEB_CONFIG does not exist.
See also
http://bugs.debian.org/450592
Signed-off-by: Gerrit Pape <pape@smarden.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of using "git-rev-list | git-diff-tree" pipeline for pickaxe
search, use git-log with appropriate options. Besides reducing number
of forks by one, this allows to use list form of open, which in turn
allow to not worry about quoting arguments and to avoid forking shell.
The options to git-log were chosen to reduce required changes in
pickaxe git command output parsing; gitweb still parses returned
commits one by one.
Parsing "pickaxe" output is simplified: git_search now reuses
parse_difftree_raw_line and writes affected files as they arrive using
the fact that commit name goes always before [raw] diff.
While at it long bug of pickaxe search was fixed, namely that the last
commit found by pickaxe search was never shown.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to greediness of a pattern, gitweb used to mark (show) last match
in line, if there are more than one match in line. Now it shows first.
Showing all matches in a line would require further work.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch does a couple of things:
* Makes commit/author/committer search case insensitive
To be consistent with the grep search; I see no convincing
reason for the search to be case sensitive, and you might
get in trouble especially with contributors e.g. from Japan
or France where they sometimes like to uppercase their last
name.
* Makes grep search by default search for fixed strings.
* Introduces 're' checkbox that enables POSIX extended regexp searches
This works for all the search types. The idea comes from Jakub.
It does not make much sense (and is not easy at all) to untangle most
of these changes from each other, thus they all go in a single patch.
[jn: Cherry-picked from Pasky's http://repo.or.cz/git/gitweb.git]
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use '--fixed-strings' option to git-rev-list to simplify and improve
searching commit messages (commit search). It allows to search for
example for "don't" successfully from gitweb.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change order of parameters in parse_commits() to have $filename
before @args (extra options), to allow for multiple extra options,
for example both '--grep=<pattern>' and '--fixed-strings'.
Change all callers to follow new calling convention.
Originally by Petr Baudis, in http://repo.or.cz/git/gitweb.git:
b98f0a7c gitweb: Clearly distinguish regexp / exact match searches
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve look of commit search output ('search' view) by better cutting
of matched string and its context in match info, as suggested by Junio.
For example, if you are looking for "very long search string" in the
following line:
Could somebody test this with very long search string, and see how
you would now see:
...this with <<very long ... string>>, and see...
instead of:
Could som... <<very long search...>>, and see...
(where <<something>> denotes emphasized / colored fragment; matched
fragment to be more exact).
For this feature, support for fourth [optional] parameter to chop_str
subroutine was added. This fourth parameter is used to denote where
to cut string to make it shorter. chop_str can now cut at the
beginning (from the _left_ side of the string), in the middle
(_center_ of the string), or at the end (from the _right_ side of
the string); cutting from right is the default:
chop_str(somestring, len, slop, 'left') -> ' ...string'
chop_str(somestring, len, slop, 'center') -> 'som ... ing'
chop_str(somestring, len, slop, 'right') -> 'somestr... '
If you want to use default slop (default additional length), use undef
as value for third parameter to chop_str.
While at it, return from chop_str early if given string is so short
that chop_str couldn't shorten it. Simplify also regexp used by
chop_str. Make ellipsis (dots) stick to shortened fragment for
cutting at ends, to better see which part got shortened.
Simplify passing all arguments to chop_str in chop_and_escape_str
subroutine. This was needed to pass additional options to chop_str.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use int(<expr>/2) to get integer value for a substring length.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When searching commit messages (commit search), if matched string is
too long, the generated HTML was munged leading to an ill-formed XHTML
document.
Now gitweb chop leading, trailing and matched parts, HTML escapes
those parts, then composes and marks up match info. HTML output is
never chopped. Limiting matched info to 80 columns (with slop) is now
done by dividing remaining characters after chopping match equally to
leading and trailing part, not by chopping composed and HTML marked
output.
Noticed-by: Jean-Baptiste Quenot <jbq@caraldi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
URLs generated by href(..., -replay=>1) (which includes 'next page'
links and alternate view links) didn't set project info correctly
when current page URL is in pathinfo form.
This resulted in broken links such like:
http://www.example.com/w/ARRAY(0x85a5318)?a=shortlog;pg=1
if the 'pathinfo' feature was used, or
http://www.example.com/w/?a=shortlog;pg=1
if it wasn't, instead of correct:
http://www.example.com/w/project.git?a=shortlog;pg=1
This was caused by the fact that href() always replays params in the
arrayref form, were they multivalued or singlevalued, and the code
dealing with 'pathinfo' feature couldn't deal with $params{'project'}
being arrayref.
Setting $params{'project'} is moved before replaying params; this
ensures that 'project' parameter is processed correctly.
Noticed-by: Peter Oberndorfer <kumbayo84@arcor.de>
Noticed-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for new option -nohtml to quot_cec and quot_upr
subroutines, to have output not wrapped in HTML tags. This makes
those subroutines suitable to quoting attributes values, and for plain
text output quoting. Currently this API is not used yet.
While at it fix whitespace, and use ';' as delimiter, not separator.
The option to not wrap quot_cec output in HTML tag were proposed
originally in patch:
"Don't open a XML tag while another one is already open"
Message-ID: <20080216191628.GK30676@schiele.dyndns.org>
by Robert Schiele. Originally the parameter was named '-notag', was
also supportted by esc_html (but not esc_path) which passed it down to
quot_cec. Mentioned patch was meant to fix the bug Martin Koegler
reported in his mail
"Invalid html output repo.or.cz (alt-git.git)"
Message-ID: <20080216130037.GA14571@auto.tuwien.ac.at>
which was fixed in different way (do not use esc_html to escape and
quote HTML attributes).
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not use esc_html to escape [title] _attribute_ of a HTML element,
and quote unprintable characters. Replace unprintable characters by
'?' and use CGI method to generate HTML element and do the escaping.
This caused bug noticed by Martin Koegler,
Message-ID: <20080216130037.GA14571@auto.tuwien.ac.at>
that for bad commit encoding in author name, the title attribute (here
to show full, not shortened name) had embedded HTML code in it, result
of quoting unprintable characters the gitweb/HTML way. This of course
broke the HTML, causing page being not displayed in XML validating web
browsers.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now gitweb checks if gitweb.owner exists before trying to get filesystem's
owner.
Allow to use configuration variable gitweb.owner set the repository owner,
it checks the gitweb.owner, if not set it uses filesystem directory's owner.
Useful when we don't want to maintain project list file, and all
repository directories have to have the same owner (for example when the
same SSH account is shared for all projects, using ssh_acl to control
access instead).
Signed-off-by: Bruno Ribas <ribas@c3sl.ufpr.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change feeds entries (feeds items) from pointing (linking) to 'commit'
view to pointing to 'commitdiff' view.
First, feed entries have whatchanged-like list of files which were
modified in a commit, so 'commitdiff' view more naturally reflects
feed entry (is more naturally alternate / extended version of a feed
item). Second, this way the patches are shown directly and code review
is done more easily via watching feeds.
[jn: Rewritten commit message]
Signed-off-by: Florian La Roche <laroche@redhat.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the commit message, or commit author contains non-ascii, it must be
converted from Perl internal representation to utf-8, to follow what
got declared in HTTP header. Use to_utf8() to do the conversion.
This necessarily replaces here-doc with "print" statements.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Acked-by: İsmail Dönmez <ismail@pardus.org.tr>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is important for the list of clone urls, where if there are
no per-repository clone URL configured, the default base URLs
are never used for URL construction without this patch.
Add tests for different ways of setting project URLs, just in case.
Note that those tests in current form wouldn't detect breakage fixed
by this patch, as it only checks for errors and not for expected
output.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 930cf7dd7c 'blob' action knows the
file type; if the file type is not "text/*" or one of common network
image formats/mimetypes (gif, png, jpeg) then the action "blob"
defaulted to "blob_plain". This caused the problem if mimetypes file
was not well suited for web, for example returning "application/x-sh"
for "*.sh" shell scripts, instead of "text/plain" (or other "text/*").
Now "blob" action defaults to "blob_plain" ('raw' view) only if file
is of type which is neither "text/*" nor "image/{gif,png,jpeg}"
AND it is binary file. Otherwise it assumes that it can be displayed
either in <img> tag ("image/*" mimetype), or can be displayed line by
line (otherwise).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoid wrong disambiguation that would link logs/trees of tags and
heads which share the same name to the same page, leading to
a disambiguation that would prefer the tag, thus making it impossible
to access the corresponding head log and tree without hacking the url
by hand.
It does it by using full refname (with 'refs/heads/' or 'refs/tags/'
prefix) instead of shortened one in the URLs in 'heads' and 'tags'
tables. This makes URLs (and refs) provided by gitweb unambiguous.
Signed-off-by: Guillaume Seguin <guillaume@segu.in>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: İsmail Dönmez <ismail@pardus.org.tr>
Tested-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Put (optional) projects README on "summary" page in <div> element
using "readme" class. This allow to style it using CSS.
Add padding to project's README to make it line out with the rest
of the page.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Remove all cellspacing="0" attributes from tables in gitweb,
replacing it by CSS rule. Add CSS classes for all tables.
While at it, change class(es) of table for commit message and commit
authorship search from "grep" to "commit_search"; similarly,
"grep_search" class is now used for table with results of grep (files)
search.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
* maint:
fix index-pack with packs >4GB containing deltas on 32-bit machines
git-hash-object should honor config variables
gitweb: correct month in date display for atom feeds
Allow to use configuration variable gitweb.description for repository
description if there is no $GIT_DIR/description file, and multivalued
configuration variable gitweb.url for URLs of a project (to clone or
fetch from) if there is no $GIT_DIR/cloneurl file.
While repository description is shown in the projects list page, so it
is better to use file and not config variable for performance, it is I
think better to use gitweb.url for URLs (as it is shown only on
project summary page).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change git_get_project_config to run git-config only once per
repository, without changing its signature (its calling convention).
This means for example that it returns 'true' or 'false' when called
with second argument '--bool', and not true or false value.
Instead of calling 'git config [<type>] --get gitweb.<key>' once for
each config variable, call 'git config -z -l' only once, parsing and
saving its output to %config variable. This makes possible to add new
per repository configuration without paying cost of forking once per
variable checked. We can now allow repository description and
repository URLs to be stored in config file without badly affecting
gitweb performance.
For now only configuration variables for 'gitweb' section are stored.
Multiple values for single configuration variable are stored as
anonymous array reference; configuration variable with no value is
stored as undef.
Converting configuration variable values to boolean or integer value
are done in Perl. Results differ from git-config in the fact that no
conversion error is ever raised. For boolean values no value, 'true'
(any case) and 'false' (any case) are considered true, numbers are
true if not zero; all other values (even invalid for bool) are
considered false. For integer values value suffix of 'k', 'm', or 'g'
following decimal number will cause the value to be multiplied by
1024, 1048576, or 1073741824; other values are returned as-is, only
whitespace stripped.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use href(action=>..., -replay=>1) to generate links to alternate views
of current page in the $formats_nav (bottom) part of page_nav
navigation bar. This form is used only when all parameters are
repeated, and when the replay form is shorter.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use href(-replay=>1, page=>$page-1) and href(-replay=>1, page=>$page+1)
to generate previous page and next page links.
Generate next page link only once.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add boolean option '-replay' to href() subroutine, which is used to
generate links in gitweb. This option "replays" current URL,
overriding it with provided parameters. It means that current value
of each CGI parameter is used unless otherwise provided.
This change is meant to make it easier to generate links which differ
from current page URL only by one parameter, for example the same view
but sorted by different column:
href(-replay=>1, order=>"age")
or view which differs by some option, e.g. in log views
href(-replay=>1, extra_options=>"--no-merges")
or alternate view of the same object, e.g. in the 'blob' view
href(-replay=>1, action=>"blob_plain")
Actual use of this functionality is left for later.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 'status_str' to diffinfo output, which stores status (also for
merge commit) as a string. This allows for easy checking if there is
given status among all for merge commit, e.g.
$diffinfo->{'status_str'} =~ /D/;
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Always set 'from_file' and 'to_file' keys when parsing raw diff output
format line, even if filename didn't change (file was not renamed).
This allows for simpler code.
Previously, you would have written:
$diffinfo->{'from_file'} || $diffinfo->{'file'}
but now you can just use
$diffinfo->{'from_file'}
as 'from_file' is always defined.
While at it, replace (for merge commits)
$diffinfo->{'from_file'}[$i] || $diffinfo->{'to_file'}
by
defined $diffinfo->{'from_file'}[$i] ?
$diffinfo->{'from_file'}[$i] :
$diffinfo->{'to_file'};
to have no problems with file named '0'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
