summaryrefslogtreecommitdiff
path: root/gitweb
AgeCommit message (Collapse)AuthorFilesLines
2012-04-29Merge branch 'kk/gitweb-omit-expensive'Libravatar Junio C Hamano1-10/+25
"gitweb" learned to optionally omit output of fields that are expensive to generate. By Kacper Kornet * kk/gitweb-omit-expensive: gitweb: Option to not display information about owner gitweb: Option to omit column with time of the last change
2012-04-29Merge branch 'kk/maint-gitweb-missing-owner'Libravatar Junio C Hamano1-2/+4
By Kacper Kornet * kk/maint-gitweb-missing-owner: gitweb: Don't set owner if got empty value from projects.list
2012-04-26gitweb: Option to not display information about ownerLibravatar Kacper Kornet1-6/+15
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>
2012-04-25gitweb: Option to omit column with time of the last changeLibravatar Kacper Kornet1-5/+11
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>
2012-04-25gitweb: Don't set owner if got empty value from projects.listLibravatar Kacper Kornet1-2/+4
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>
2012-04-24Merge branch 'mk/gitweb-diff-hl'Libravatar Junio C Hamano2-87/+244
"gitweb" learns to highlight the patch it outputs even more. By Michał Kiedrowicz (7) and Jakub Narębski (1) * mk/gitweb-diff-hl: gitweb: Refinement highlightning in combined diffs gitweb: Highlight interesting parts of diff gitweb: Push formatting diff lines to print_diff_chunk() gitweb: Use print_diff_chunk() for both side-by-side and inline diffs gitweb: Extract print_sidebyside_diff_lines() gitweb: Pass esc_html_hl_regions() options to esc_html() gitweb: esc_html_hl_regions(): Don't create empty <span> elements gitweb: Use descriptive names in esc_html_hl_regions()
2012-04-16Merge branch 'wk/gitweb-snapshot-use-if-modified-since'Libravatar Junio C Hamano1-26/+39
Makes 'snapshot' request to "gitweb" honor If-Modified-Since: header, based on the commit date. By W. Trevor King * wk/gitweb-snapshot-use-if-modified-since: gitweb: add If-Modified-Since handling to git_snapshot(). gitweb: refactor If-Modified-Since handling gitweb: add `status` headers to git_feed() responses.
2012-04-11gitweb: Refinement highlightning in combined diffsLibravatar Michał Kiedrowicz1-13/+42
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>
2012-04-11gitweb: Highlight interesting parts of diffLibravatar Michał Kiedrowicz2-12/+103
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>
2012-04-11gitweb: Push formatting diff lines to print_diff_chunk()Libravatar Michał Kiedrowicz1-19/+18
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>
2012-04-11gitweb: Use print_diff_chunk() for both side-by-side and inline diffsLibravatar Michał Kiedrowicz1-16/+39
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>
2012-04-11gitweb: Extract print_sidebyside_diff_lines()Libravatar Michał Kiedrowicz1-45/+51
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>
2012-04-11gitweb: Pass esc_html_hl_regions() options to esc_html()Libravatar Jakub Narębski1-4/+7
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>
2012-04-11gitweb: esc_html_hl_regions(): Don't create empty <span> elementsLibravatar Michał Kiedrowicz1-0/+3
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>
2012-04-11gitweb: Use descriptive names in esc_html_hl_regions()Libravatar Michał Kiedrowicz1-5/+8
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>
2012-04-11gitweb: Fix unintended "--no-merges" for regular Atom feedLibravatar Sebastian Pipping1-0/+1
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>
2012-03-30gitweb: add If-Modified-Since handling to git_snapshot().Libravatar W. Trevor King1-0/+10
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>
2012-03-30gitweb: refactor If-Modified-Since handlingLibravatar W. Trevor King1-28/+29
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>
2012-03-30gitweb: add `status` headers to git_feed() responses.Libravatar W. Trevor King1-2/+4
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>
2012-03-28correct a few doubled-word nits in comments and documentationLibravatar Jim Meyering1-1/+1
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>
2012-03-08Merge branch 'jn/maint-do-not-match-with-unsanitized-searchtext'Libravatar Junio C Hamano1-9/+9
By Jakub Narebski * jn/maint-do-not-match-with-unsanitized-searchtext: gitweb: Fix fixed string (non-regexp) project search Conflicts: gitweb/gitweb.perl
2012-03-06gitweb: Fix fixed string (non-regexp) project searchLibravatar Jakub Narebski1-8/+8
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>
2012-03-04Merge branch 'jn/gitweb-hilite-regions'Libravatar Junio C Hamano1-3/+92
* jn/gitweb-hilite-regions: gitweb: Highlight matched part of shortened project description gitweb: Highlight matched part of project description when searching projects gitweb: Highlight matched part of project name when searching projects gitweb: Introduce esc_html_match_hl and esc_html_hl_regions
2012-03-02gitweb: Fix passing parameters to git_project_search_formLibravatar Jakub Narebski1-1/+1
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>
2012-03-01Merge branch 'jn/maint-gitweb-invalid-regexp'Libravatar Junio C Hamano1-1/+10
* jn/maint-gitweb-invalid-regexp: gitweb: Handle invalid regexp in regexp search
2012-02-28gitweb: Handle invalid regexp in regexp searchLibravatar Jakub Narebski1-1/+10
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>
2012-02-26Merge branch 'jn/gitweb-search-optim'Libravatar Junio C Hamano1-13/+53
* jn/gitweb-search-optim: gitweb: Faster project search gitweb: Option for filling only specified info in fill_project_list_info gitweb: Refactor checking if part of project info need filling
2012-02-26gitweb: Highlight matched part of shortened project descriptionLibravatar Jakub Narebski1-5/+47
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>
2012-02-26gitweb: Highlight matched part of project description when searching projectsLibravatar Jakub Narebski1-2/+6
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>
2012-02-26gitweb: Highlight matched part of project name when searching projectsLibravatar Jakub Narebski1-1/+3
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>
2012-02-26gitweb: Introduce esc_html_match_hl and esc_html_hl_regionsLibravatar Jakub Narebski1-0/+41
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>
2012-02-23gitweb: Faster project searchLibravatar Jakub Narebski1-2/+7
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>
2012-02-23gitweb: Option for filling only specified info in fill_project_list_infoLibravatar Jakub Narebski1-8/+25
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>
2012-02-23gitweb: Refactor checking if part of project info need fillingLibravatar Jakub Narebski1-8/+26
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>
2012-02-21Merge branch 'jn/gitweb-unborn-head'Libravatar Junio C Hamano1-2/+2
* jn/gitweb-unborn-head: gitweb: Fix "heads" view when there is no current branch
2012-02-20Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* maint: Update draft release notes to 1.7.9.2 gitweb: Fix 'grep' search for multiple matches in file
2012-02-19gitweb: Fix 'grep' search for multiple matches in fileLibravatar Jakub Narebski1-1/+2
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>
2012-02-17gitweb: Fix "heads" view when there is no current branchLibravatar Jakub Narebski1-2/+2
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>
2012-02-14Merge branch 'bl/gitweb-project-filter'Libravatar Junio C Hamano1-1/+1
* bl/gitweb-project-filter: gitweb: Harden and improve $project_filter page title
2012-02-12Merge branch 'jn/gitweb-search-utf-8'Libravatar Junio C Hamano1-7/+7
* jn/gitweb-search-utf-8: gitweb: Allow UTF-8 encoded CGI query parameters and path_info Conflicts: gitweb/gitweb.perl
2012-02-12gitweb: Harden and improve $project_filter page titleLibravatar Jakub Narebski1-1/+1
Commit 19d2d23 (gitweb: add project_filter to limit project list to a subdirectory, 2012-01-30) added also support for displaying $project_filter, if present, in page title. Unfortunately it forgot to treat $project_filter as path, and escape it using esc_path(), like it is done for $filename. Also, it was not obvious that "$site_name - $project_filter" is about project filtering: use "$site_name - projects in '$project_filter'". Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07Merge branch 'bl/gitweb-project-filter'Libravatar Junio C Hamano2-20/+95
* bl/gitweb-project-filter: gitweb: Make project search respect project_filter gitweb: improve usability of projects search form gitweb: place links to parent directories in page header gitweb: show active project_filter in project_list page header gitweb: limit links to alternate forms of project_list to active project_filter gitweb: add project_filter to limit project list to a subdirectory gitweb: prepare git_get_projects_list for use outside 'forks'. gitweb: move hard coded .git suffix out of git_get_projects_list
2012-02-03gitweb: Allow UTF-8 encoded CGI query parameters and path_infoLibravatar Jakub Narebski1-8/+8
Gitweb forgot to turn query parameters into UTF-8. This results in a bug that one cannot search for a string with characters outside US-ASCII. For example searching for "Michał Kiedrowicz" (containing letter 'ł' - LATIN SMALL LETTER L WITH STROKE, with Unicode codepoint U+0142, represented with 0xc5 0x82 bytes in UTF-8 and percent-encoded as %C5%82) result in the following incorrect data in search field MichaÅ\202 Kiedrowicz This is caused by CGI by default treating '0xc5 0x82' bytes as two characters in Perl legacy encoding latin-1 (iso-8859-1), because 's' query parameter is not processed explicitly as UTF-8 encoded string. The solution used here follows "Using Unicode in a Perl CGI script" article on http://www.lemoda.net/cgi/perl-unicode/index.html: use CGI; use Encode 'decode_utf8; my $value = params('input'); $value = decode_utf8($value); Decoding UTF-8 is done when filling %input_params hash and $path_info variable; the former requires to move from explicit $cgi->param(<label>) to $input_params{<name>} in a few places, which is a good idea anyway. Also add -override=>1 parameter to $cgi->textfield() invocation in search form. Otherwise CGI would use values from query string if it is present, filling value from $cgi->param... without decode_utf8(). As we are using value of appropriate parameter anyway, -override=>1 doesn't change the situation but makes gitweb fill search field correctly. We could simply use the '-utf8' pragma (via "use CGI '-utf8';") to solve this, but according to CGI.pm documentation, it may cause problems with POST requests containing binary files, and it requires CGI 3.31 (I think), released with perl v5.8.9. Reported-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Jakub Narębski <jnareb@gmail.com> Tested-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01gitweb: Make project search respect project_filterLibravatar Jakub Narebski1-5/+13
Make gitweb search within filtered projects (i.e. projects shown), and change "List all projects" to "List all projects in '$project_filter/'" if project_filter is used. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01gitweb: improve usability of projects search formLibravatar Jakub Narebski2-6/+28
Refactor generating project search form into git_project_search_form(). Make text field wider and add on mouse over explanation (via "title" attribute), add an option to use regular expressions, and replace 'Search:' label with [Search] button. Also add "List all projects" link to make it easier to go back from search result to list of all projects (note that an empty search term is disallowed). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01gitweb: place links to parent directories in page headerLibravatar Bernhard R. Link1-1/+4
Change html page headers to not only link the project root and the currently selected project but also the directories in between using project_filter. (Allowing to jump to a list of all projects within that intermediate directory directly and making the project_filter feature visible to users). Signed-off-by: Bernhard R. Link <brlink@debian.org> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01gitweb: show active project_filter in project_list page headerLibravatar Bernhard R. Link1-0/+14
In the page header of a project_list view with a project_filter given show breadcrumbs in the page headers showing which directory it is currently limited to and also containing links to the parent directories. Signed-off-by: Bernhard R. Link <brlink@debian.org> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01gitweb: limit links to alternate forms of project_list to active project_filterLibravatar Bernhard R. Link1-2/+4
If project_list action is given a project_filter argument, pass that to TXT and OPML formats. This way [OPML] and [TXT] links provide the same list of projects as the projects_list page they are linked from. Signed-off-by: Bernhard R. Link <brlink@debian.org> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01gitweb: add project_filter to limit project list to a subdirectoryLibravatar Bernhard R. Link1-6/+25
This commit changes the project listing views (project_list, project_index and opml) to limit the output to only projects in a subdirectory if the new optional parameter ?pf=directory name is used. The implementation of the filter reuses the implementation used for the 'forks' action (i.e. listing all projects within that directory from the projects list file (GITWEB_LIST) or only projects in the given subdirectory of the project root directory without a projects list file). Reusing $project instead of adding a new parameter would have been nicer from a UI point-of-view (including PATH_INFO support) but would complicate the $project validating code that is currently being used to ensure nothing is exported that should not be viewable. Signed-off-by: Bernhard R. Link <brlink@debian.org> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01gitweb: prepare git_get_projects_list for use outside 'forks'.Libravatar Bernhard R. Link1-1/+6
Use of the filter option of git_get_projects_list is currently limited to forks. It currently assumes the project belonging to the filter directory was already validated to be visible in the project list. To make it more generic add an optional argument to denote visibility verification is still needed. If there is a projects list file (GITWEB_LIST) only projects from this list are returned anyway, so no more checks needed. If there is no projects list file and the caller requests strict checking (GITWEB_STRICT_EXPORT), do not jump directly to the given directory but instead do a normal search and filter the results instead. The only effect of GITWEB_STRICT_EXPORT without GITWEB_LIST is to make sure no project can be viewed without also be found starting from project root. git_get_projects_list without this patch does not enforce this but all callers only call it with a filter already checked this way. With this parameter a caller can request this check if the filter cannot be checked this way. Signed-off-by: Bernhard R. Link <brlink@debian.org> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>