Change the @author_initials feature Jakub added in
v1.6.4-rc2-14-ga36817b to match non-ASCII author initials as intended.
The regexp Jakub added was intended to match
non-ASCII (/\b([[:upper:]])\B/g). But in Perl this doesn't actually
match non-ASCII upper-case characters unless the string being matched
against has the UTF8 flag.
So when we open a pipe to "git blame" we need to mark the file
descriptor we're opening as utf8 explicitly.
So as a result it abbreviates me to "AB" not "ÆAB", entirely because "Æ"
isn't /[[:upper:]]/ unless the string being matched against has the UTF8
flag.
Here's something that demonstrates the issue:
#!/usr/bin/env perl
use strict;
use warnings;
binmode STDOUT, ':utf8' if $ENV{UTF8};
open my $fd, "-|", "git", "blame", "--incremental", "--", "Makefile" or die "Can't open: $!";
binmode $fd, ":utf8" if $ENV{UTF8};
while (my $line = <$fd>) {
next unless my ($author) = $line =~ /^author (.*)/;
my @author_initials = ($author =~ /\b([[:upper:]])\B/g);
printf "%s (%s)\n", join("", @author_initials), $author;
}
When that's run with and without UTF8 being true in the environment it
gives, on git.git:
$ UTF8=0 perl author-initials.pl | sort | uniq -c |
sort -nr | head -n 5
99 JH (Junio C Hamano)
35 JN (Jonathan Nieder)
35 JK (Jeff King)
20 JS (Johannes Schindelin)
16 AB (Ævar Arnfjörð Bjarmason)
$ UTF8=1 perl author-initials.pl | sort | uniq -c |
sort -nr | head -n 5
99 JH (Junio C Hamano)
35 JN (Jonathan Nieder)
35 JK (Jeff King)
20 JS (Johannes Schindelin)
16 ÆAB (Ævar Arnfjörð Bjarmason)
Acked-by: Jakub Narębski <jnareb@gmail.com>
Tested-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Tested-by: Simon Ruderich <simon@ruderich.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The search help link was a superscript question mark right next to
a drop-down menu, which looks misaligned and is a cramped and
awkward click target. Remove the superscript tags and add some
spacing to fix these nits. Add a title attribute to provide an
explanatory mouseover.
Signed-off-by: Tony Finch <dot@dotat.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On the repository summary page, leave the owner line out if the
repo does not have an owner, rather than displaying a labelled empty
field. This does not affect the owner column in the projects list
page, which is present unless $omit_owner is true.
Signed-off-by: Tony Finch <dot@dotat.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rss_logo CSS style has a fixed width which is too narrow for
the string "OPML". Replace the fixed width with horizontal padding
so the text fits with nice margins.
Signed-off-by: Tony Finch <dot@dotat.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Signed-off-by: Tony Finch <dot@dotat.at>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The bug is manifest when running gitweb in a persistent process (e.g.
FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
includes the searchtext parameter (i.e. s), subsequent requests using
the project_list action--which is the default action--and without
a searchtext parameter will be filtered by the searchtext value of the
first request. This is because the value of the $search_regexp global
(the value of which is based on the searchtext parameter) is currently
being persisted between requests.
Instead, clear $search_regexp before dispatching each request.
Signed-off-by: Charles McGarvey <chazmcgarvey@brokenzipper.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The flow of the text describing GITWEB_CONFIG_SYSTEM and
GITWEB_CONFIG_COMMON in gitweb/INSTALL is awkward. "This is bad. Oh
the other hand, better is broken. Therefore we do this." forces
readers to make multiple guesses while reading: "ok, bad, so you
plan to change it and warn us about upcoming change? oh, not that,
changing it is bad, so we have to live with it? oh, not that, there
is another one that is common and that is what we can use".
Better rewrite said paragraph to avoid such a mental roller-coaster in
the first place.
Signed-off-by: Junio Hamano <gitster@pobox.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of these were found using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of these were found using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git.kernel.org no longer uses gitweb but has switched to cgit.
Info about this can be found on: https://www.kernel.org/pelican.html
or simply by looking at http://git.kernel.org . This is change since
2013-03-01.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the current code, the images from picon and gravatar are
requested over http://, and browsers give mixed contents warning
when gitweb is served over https://.
Just drop the scheme: part from the URL, so that these external
sites are accessed over https:// in such a case.
Signed-off-by: Andrej E Baranov <admin@andrej-andb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$1 becomes undef by internal regex, since it has no capture groups.
Match against accpetable control characters using index() instead of a regex.
Signed-off-by: Orgad Shaneh <orgads@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sorting gitweb's project list by age ('Last Change') currently shows
projects with undefined ages at the head of the list. This gives a less
useful result when there are a number of projects that are missing or
otherwise faulty and one is trying to see what projects have been
updated recently.
Fix by sorting these projects with undefined ages at the bottom of the
list when sorting by age.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git configuration items can not contain underscores in their section
and bottom-level variable name; the 'remote_heads' feature can not
be enabled on a per-repository basis with that name.
This changes the git-config option to be `gitweb.remoteheads` but does
not change the gitweb.conf option, to avoid backwards compatibility
issues. We strip underscores from keys before looking through
git-config output for them.
An existing check on keynames was overly eager to reject non-word
letters, but if we ever start using three-level names, the middle
level string can contain almost anything, so fix that as well while
we are in the vicinity.
Signed-off-by: Phil Pennock <phil@apcera.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The title of an RSS feed is generated from many components,
including the filename provided as a query parameter, but we
failed to quote it. Besides showing the wrong output, this
is a vector for XSS attacks.
Signed-off-by: Jeff King <peff@peff.net>
When commit 592ea41 refactored the list of extensions for
syntax highlighting, it failed to take into account perl's
operator precedence within lists. As a result, we end up
creating a dictionary of one-to-one elements when the intent
was to map mutliple related types to one main type (e.g.,
bash, ksh, zsh, and sh should all map to sh since they share
similar syntax, but we ended up just mapping "bash" to
"bash" and so forth).
This patch adds parentheses to make the mapping as the
original change intended. It also reorganizes the list to
keep mapped extensions together.
Signed-off-by: Richard Hubbell <richard_hubbe11@lavabit.com>
Signed-off-by: Jeff King <peff@peff.net>
gitweb's feeds sometimes contained committer timestamps in the wrong timezone
due to a misspelling.
Signed-off-by: Dylan Simon <dylan@dylex.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When gitweb is used as a DirectoryIndex, it attempts to strip
PATH_INFO on its own, as $cgi->url() fails to do so.
However, it fails to account for the fact that PATH_INFO has
already been URL-decoded by the web server, but the value
returned by $cgi->url() has not been. This causes the stripping
to fail whenever the URL contains encoded characters.
To see this in action, setup gitweb as a DirectoryIndex and
then use it on a repository with a directory containing a
space in the name. Navigate to tree view, examine the gitweb
generated html and you'll see a link such as:
<a href="/test.git/tree/HEAD:/directory with spaces">directory with spaces</a>
When clicked on, the browser will URL-encode this link, giving
a $cgi->url() of the form:
/test.git/tree/HEAD:/directory%20with%20spaces
While PATH_INFO is:
/test.git/tree/HEAD:/directory with spaces
Fix this by calling unescape() on both $my_url and $my_uri before
stripping PATH_INFO from them.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tip tree is the one of major subsystem tree in the
Linux kernel project. On the tip tree, the Link: (or
similar Buglink:) tag is used for tracking the original
discussion or context. Since it's ususally in the S-o-b
area, it'd be better using same style with others.
Also as it tends to contain a message-id sent from git
send-email, a part of the line would set a wrong hyperlink
like [1]. Fix it by not using format_log_line_html().
[1] git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=08942f6d5d992e9486b07653fd87ea8182a22fa0
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are many types of tags used in S-o-b area [1].
Update the regex to handle them properly. It requires
the tag should be started by a capital letter and ended
by '-by: ' or '-By: '. The only exception is 'Cc: '.
[1] http://lwn.net/Articles/503829/
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we see a signed-off-by line (and its friends), we set $signoff
to true, but then we process the next line after we are done without
giving control to the rest of the loop. And when the line we saw is
not a signed-off-by line, we reset $signoff to false before running
the remainder of the loop.
Hence, the check for $signoff that attempts to remove an extra empty
line between two signed-off-by line was not doing anything useful.
Rename $empty to a more explicit name $skip_blank_line to tell us to
skip a blank line when we see one, set it after we see and emit a
blank line (to avoid showing more than one empty lines in a raw) or
after we handle a signed-off-by line (to avoid empty lines after
such a line), to fix this bug, and get rid of the $signoff variable
that is not useful.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some setups the repository owner is not a well defined concept
and administrator can prefer it to be not shown. This commit add
and an option that enable to reach this effect.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Generating information about last change for a large number of git
repositories can be very time consuming. This commit add an option to
omit 'Last Change' column when presenting the list of repositories.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prevent setting owner to an empty value if it is not specified in
projects.list file. Otherwise it stops retrieving information about the
owner from other files.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The highlightning of combined diffs is currently disabled. This is
because output from a combined diff is much harder to highlight because
it is not obvious which removed and added lines should be compared.
Current code requires that the number of added lines is equal to the
number of removed lines and only skips first +/- character, treating
second +/- as a line content, Thus, it is not possible to simply use
existing algorithm unchanged for combined diffs.
Let's start with a simple case: only highlight changes that come from
one parent, i.e. when every removed line has a corresponding added line
for the same parent. This way the highlightning cannot get wrong. For
example, following diffs would be highlighted:
- removed line for first parent
+ added line for first parent
context line
-removed line for second parent
+added line for second parent
or
- removed line for first parent
-removed line for second parent
+ added line for first parent
+added line for second parent
but following output will not:
- removed line for first parent
-removed line for second parent
+added line for second parent
++added line for both parents
In other words, we require that pattern of '-'-es in pre-image matches
pattern of '+'-es in post-image.
Further changes may introduce more intelligent approach that better
handles combined diffs.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reading diff output is sometimes very hard, even if it's colored,
especially if lines differ only in few characters. This is often true
when a commit fixes a typo or renames some variables or functions.
This commit teaches gitweb to highlight characters that are different
between old and new line with a light green/red background. This should
work in the similar manner as in Trac or GitHub.
The algorithm that compares lines is based on contrib/diff-highlight.
Basically, it works by determining common prefix/suffix of corresponding
lines and highlightning only the middle part of lines. For more
information, see contrib/diff-highlight/README.
Combined diffs are not supported but a following commit will change it.
Since we need to pass esc_html()'ed or esc_html_hl_regions()'ed lines to
format_diff_lines(), so it was taught to accept preformatted lines
passed as a reference.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now lines are formatted closer to place where we actually use HTML
formatted output.
This means that we put raw lines in the @chunk accumulator, rather than
formatted lines. Because we still need to know class (type) of line
when accumulating data to post-process and print, process_diff_line()
subroutine was retired and replaced by diff_line_class() used in
git_patchset_body() and new restructured format_diff_line() used in
print_diff_chunk().
As a side effect, we have to pass \%from and \%to down to callstack.
This is a preparation patch for diff refinement highlightning. It's not
meant to change gitweb output.
[jn: wrote commit message]
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This renames print_sidebyside_diff_chunk() to print_diff_chunk() and
makes use of it for both side-by-side and inline diffs. Now diff lines
are always accumulated before they are printed. This opens the
possibility to preprocess diff output before it's printed, which is
needed for diff refinement highlightning (implemented in incoming
patches).
If print_diff_chunk() was left as is, the new function
print_inline_diff_lines() could reorder diff lines. It first prints all
context lines, then all removed lines and finally all added lines. If
the diff output consisted of mixed added and removed lines, gitweb would
reorder these lines. This is true for combined diff output, for
example:
- removed line for first parent
+ added line for first parent
-removed line for second parent
++added line for both parents
would be rendered as:
- removed line for first parent
-removed line for second parent
+ added line for first parent
++added line for both parents
To prevent gitweb from reordering lines, print_diff_chunk() calls
print_diff_lines() as soon as it detects that both added and removed
lines are present and there was a class change, and at the end of chunk.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, print_sidebyside_diff_chunk() does two things: it
accumulates diff lines and prints them. Accumulation may be used to
perform additional operations on diff lines, so it makes sense to split
these two things. Thus, whole code that formats and prints diff lines
in the 'side-by-side' manner is moved out of print_sidebyside_diff_chunk()
to a separate subroutine and two conditions that control printing
diff liens are merged.
Thanks to that, we can easily (in later patches) replace call to that
subroutine with a call to more generic print_diff_lines() that will
control whether 'inline' or 'side-by-side' diff should be printed.
As a side effect, context lines are printed just before printing added
and removed lines, and at the end of chunk (previously, they were
printed immediately on the class change). However, this doesn't change
gitweb output.
The outcome of this patch is that print_sidebyside_diff_chunk() is now
much shorter and easier to read.
While at it, drop the '# assume that it is change' comment. According
to Jakub Narębski:
What I meant here when I was writing it that they are lines that
changed between two versions, like '!' in original (not unified)
context format.
We can omit this comment.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this change, esc_html_hl_regions() accepts options and passes them
down to esc_html(). This may be needed if a caller wants to pass
-nbsp=>1 to esc_html().
The idea and implementation example of this change was described in
337da8d2 (gitweb: Introduce esc_html_match_hl and esc_html_hl_regions,
2012-02-27). While other suggestions may be more useful in some cases,
there is no need to implement them at the moment. The
esc_html_hl_regions() interface may be changed later if it's needed.
[mk: extracted from larger patch and wrote commit message]
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If $end is equal to or less than $begin, esc_html_hl_regions()
generates an empty <span> element. It normally shouldn't be visible in
the web browser, but it doesn't look good when looking at page source.
It also minimally increases generated page size for no special reason.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The $s->[0] and $s->[1] variables look a bit cryptic. Let's rename them
to $begin and $end so that it's clear what they do.
Suggested-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The print_feed_meta() subroutine generates links for feeds with and
without merges, in RSS and Atom formats. However because %href_params
was not properly reset, it generated links with "--no-merges" for all
except the very first link.
Before:
<link rel="alternate" title="[..] - Atom feed" href="/?p=.git;a=atom;opt=--no-merges" type="application/atom+xml" />
<link rel="alternate" title="[..] - Atom feed (no merges)" href="/?p=.git;a=atom;opt=--no-merges" type="application/atom+xml" />
After:
<link rel="alternate" title="[..] - Atom feed" href="/?p=.git;a=atom" type="application/atom+xml" />
<link rel="alternate" title="[..] - Atom feed (no merges)" href="/?p=.git;a=atom;opt=--no-merges" type="application/atom+xml" />
Signed-off-by: Sebastian Pipping <sebastian@pipping.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because snapshots can be large, you can save some bandwidth by
supporting caching via If-Modified-Since. This patch adds support for
the i-m-s request to git_snapshot() if the request is a commit.
Requests for snapshots of trees, which lack well defined timestamps,
are still handled as they were before.
Signed-off-by: W Trevor King <wking@drexel.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current gitweb only generates Last-Modified and handles
If-Modified-Since headers for the git_feed action. This patch breaks
the Last-Modified and If-Modified-Since handling code out from
git_feed into a new function exit_if_unmodified_since. This makes the
code easy to reuse for other actions.
Only gitweb actions which can easily calculate a modification time
should use exit_if_unmodified_since, as the goal is to balance local
processing time vs. upload bandwidth.
Signed-off-by: W Trevor King <wking@drexel.edu>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git_feed() method was not setting a `Status` header unless it was
responding to an If-Modified-Since request with `304 Not Modified`.
Now, when it is serving successful responses, it sets status to `200
OK`.
Signed-off-by: W Trevor King <wking@drexel.edu>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Found by running this command:
$ git ls-files -z|xargs -0 perl -0777 -n \
-e 'while (/\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt]o)\s+\1\b/gims)' \
-e ' {' \
-e ' $n = ($` =~ tr/\n/\n/ + 1);' \
-e ' ($v = $&) =~ s/\n/\\n/g;' \
-e ' print "$ARGV:$n:$v\n";' \
-e ' }'
Why not just git grep -E ...?
That wouldn't work then the doubled words are separated by a newline.
This is derived from a Makefile syntax-check rule in gnulib's maint.mk:
http://git.sv.gnu.org/cgit/gnulib.git/tree/top/maint.mk
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use $search_regexp, where regex metacharacters are quoted, for
searching projects list, rather than $searchtext, which contains
original search term.
Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git_project_search_form() subroutine, introduced in a1e1b2d
(gitweb: improve usability of projects search form, 2012-01-31) didn't
get its arguments from caller correctly. Gitweb worked correctly
thanks to sticky-ness of form fields in CGI.pm... but it make UTF-8
fix for project search not working.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using regexp search ('sr' parameter / $search_use_regexp variable
is true), check first that regexp is valid.
Without this patch we would get an error from Perl during search (if
searching is performed by gitweb), or highlighting matches substring
(if applicable), if user provided invalid regexp... which means broken
HTML, with error page (including HTTP headers) generated after gitweb
already produced some output.
Add test that illustrates such error: for example for regexp "*\.git"
we would get the following error:
Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE \.git/
at /var/www/cgi-bin/gitweb.cgi line 3084.
Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previous commit make gitweb use esc_html_match_hl() to mark match in
the _whole_ description of a project when searching projects.
This commit makes gitweb highlight match in _shortened_ description,
based on match in whole description, using esc_html_match_hl_chopped()
subroutine.
If match is in removed (chopped) part, even partially, then trailing
"... " is highlighted.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use esc_html_match_hl() from earlier commit to mark match in the
_whole_ description when searching projects.
Currently, with this commit, when searching projects there is always
shown full description of a project, and not a shortened one (like for
ordinary projects list view), even if the match is on project name and
not project description. Because we always show full description of a
project, and not possibly shortened name, there is no need for having
full description on mouseover via title attribute.
Showing full description when there is match on it is useful to avoid
situation where match is in shortened, invisible part. On the other
hand that makes project search different than projects list view; also
there can be problems with overly-long project descriptions.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use esc_html_match_hl() introduced in previous commit to escape HTML
and mark match, using span element with 'match' class. Currently only
the 'path' part (i.e. the project name) is highlighted; match might be
on the project description. Highlighting match in description is left
for next commit.
The code makes use of the fact that defined $search_regexp means that
there was search going on.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The esc_html_match_hl() subroutine added in this commit will be used
to highlight *all* matches of given regexp, using 'match' class.
Ultimately it is to be used in all match highlighting, starting
with project search, which does not have it yet.
It uses the esc_html_hl_regions() subroutine, which is meant to
highlight in a given string a list of regions (given as a list of
[ beg, end ] pairs of positions in string), using HTML <span> element
with given class. It could probably be used in other places that
do highlighting of part of ready line, like highlighting of changes
in a diff (diff refinement highlighting).
Implementation and enhancement notes:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Currently esc_html_hl_regions() subroutine doesn't accept any
parameters, like esc_html() does. We might want for example to
pass nbsp=>1 to it.
It can easily be done with the following code:
my %opts = grep { ref($_) ne "ARRAY" } @sel;
@sel = grep { ref($_) eq "ARRAY" } @sel;
This allow adding parameters after or before regions, e.g.:
esc_html_hl_regions("foo bar", "mark", [ 0, 3 ], -nbsp => 1);
* esc_html_hl_regions() escapes like esc_html(); if we wanted to
highlight with esc_path(), we could pass subroutine reference
to now named esc_gen_hl_regions().
esc_html_hl_regions("foo bar", "mark", \&esc_path, [ 0, 3 ]);
Note that this way we can handle -nbsp=>1 case automatically,
e.g.
esc_html_hl_regions("foo bar", "mark",
sub { esc_html(@_, -nbsp=>1) },
[ 0, 3 ]);
* Alternate solution for highlighting region of a string would be to
use the idea that strings are to be HTML-escaped, and references to
scalars are HTML (like in the idea for generic committags).
This would require modifying gitweb code or esc_html to get list of
fragments, e.g.:
esc_html(\'<span class="mark">', 'foo', \'</span>', ' bar',
{ -nbsp => 1 });
or
esc_html([\'<span class="mark">', 'foo', \'</span>', ' bar'],
-nbsp=>1);
esc_html_match_hl() could be then simple wrapper around "match
formatter", e.g.
esc_html([ render_match_hl($str, $regexp) ], -nbsp=>1);
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before searching by some field the information we search for must be
filled in, but we do not have to fill other fields that are not
involved in the search.
To be able to request filling only specified fields,
fill_project_list_info() was enhanced in previous commit to take
additional parameters which specify part of projects info to fill.
This way we can limit doing expensive calculations (like running
git-for-each-ref to get 'age' / "Last changed" info) to doing those
only for projects which we will show as search results.
This commit actually uses this interface, changing gitweb code from
the following behavior
fill all project info on all projects
search projects
to behaving like this pseudocode
fill search fields on all projects
search projects
fill all project info on search results
With this commit the number of git commands used to generate search
results is 2*<matched projects> + 1, and depends on number of matched
projects rather than number of all projects (all repositories).
Note: this is 'git for-each-ref' to find last activity, and 'git config'
for each project, and 'git --version' once.
Example performance improvements, for search that selects 2
repositories out of 12 in total:
* Before (warm cache):
"This page took 0.867151 seconds and 27 git commands to generate."
* After (warm cache):
"This page took 0.673643 seconds and 5 git commands to generate."
Now imagine that they are 5 repositories out of 5000, and cold or
trashed cache case.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Enhance fill_project_list_info() subroutine to accept optional
parameters that specify which fields in project information needs to
be filled. If none are specified then fill_project_list_info()
behaves as it used to, and ensure that all project info is filled.
This is in preparation of future lazy filling of project info in
project search and pagination of sorted list of projects.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extract the check if given keys (given parts) of project info needs to
be filled into project_info_needs_filling() subroutine. It is for now
a thin wrapper around "!exists $project_info->{$key}".
Note that !defined was replaced by more correct !exists.
While at it uniquify treating of all project info, adding checks for
'age' field before running git_get_last_activity(), and also checking
for all keys filled in code protected by conditional, and not only
one.
The code now looks like this
foreach my $project (@$project_list) {
if (given keys need to be filled) {
fill given keys
}
...
}
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit ff7f218 (gitweb: Fix file links in "grep" search, 2012-01-05),
added $file_href variable, to reduce duplication and have the fix
applied in single place.
Unfortunately it made variable defined inside the loop, not taking into
account the fact that $file_href was set only if file changed.
Therefore for files with multiple matches $file_href was undefined for
second and subsequent matches.
Fix this bug by moving $file_href declaration outside loop.
Adds tests for almost all forms of sarch in gitweb, which were missing
from testuite. Note that it only tests if there are no warnings, and
it doesn't check that gitweb finds what it should find.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a repository whose HEAD points to an unborn branch with no commits,
"heads" view and "summary" view (which shows what is shown in "heads"
view) compared the object names of commits at the tip of branches with the
output from "git rev-parse HEAD", which caused comparison of a string with
undef and resulted in a warning in the server log.
This can happen if non-bare repository (with default 'master' branch)
is updated not via committing but by other means like push to it, or
Gerrit. It can happen also just after running "git checkout --orphan
<new branch>" but before creating any new commit on this branch.
Rewrite the comparison so that it also works when $head points at nothing;
in such a case, no branch can be "the current branch", add a test for it.
While at it, rename local variable $head to $head_at, as it points to
current commit rather than current branch name (HEAD contents).
The code still incorrectly shows all branches that point at the same
commit as what HEAD points as "the current branch", even when HEAD is
detached. Fixing this bug is outside the scope of this patch.
Reported-by: Rajesh Boyapati
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ævar Arnfjörð Bjarmason