- 20 2月, 2012 1 次提交
-
-
由 Jakub Narebski 提交于
Commit ff7f2185 (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: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 2月, 2012 1 次提交
-
-
由 Jakub Narebski 提交于
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: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 2月, 2012 1 次提交
-
-
由 Jakub Narebski 提交于
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: NMichał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: NJakub Narębski <jnareb@gmail.com> Tested-by: NMichał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 1月, 2012 2 次提交
-
-
由 Jakub Narebski 提交于
Run "git grep" in "grep" search with '-z' option, to be able to parse response also for files with filename containing ':' character. The ':' character is otherwise (without '-z') used to separate filename from line number and from matched line. Note that this does not protect files with filename containing embedded newline. This would be hard but doable for text files, and harder or even currently impossible with binary files: git does not quote filename in "Binary file <foo> matches" message, but new `--break` and/or `--header` options to git-grep could help here. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
There were two bugs in generating file links (links to "blob" view), one hidden by the other. The correct way of generating file link is href(action=>"blob", hash_base=>$co{'id'}, file_name=>$file); It was $co{'hash'} (this key does not exist, and therefore this is undef), and 'hash' instead of 'hash_base'. To have this fix applied in single place, this commit also reduces code duplication by saving file link (which is used for line links) in $file_href. Reported-by: NThomas Perl <th.perl@gmail.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 1月, 2012 1 次提交
-
-
由 Matthieu Moy 提交于
The current code is removing the trailing "/", but computing the string length on the previous value, i.e. with the trailing "/". Later in the code, we do my $path = substr($File::Find::name, $pfxlen + 1); And the "$pfxlen + 1" is supposed to mean "the length of the prefix, plus 1 for the / separating the prefix and the path", but with an incorrect $pfxlen, this basically eats the first character of the path, and yields "404 - No projects found". While we're there, also fix $pfxdepth to use $dir, although a change of 1 in the depth shouldn't really matter. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 12月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
e5d3de5c (gitweb: use Perl built-in utf8 function for UTF-8 decoding., 2007-12-04) was meant to make gitweb faster by using Perl's internals (see subsection "Messing with Perl's Internals" in Encode(3pm) manpage) Simple benchmark confirms that (old = 00f429af, new = this version): old new old -- -65% new 189% -- Unfortunately it made fallback mode of to_utf8 do not work... except for default value 'latin1' of $fallback_encoding ('latin1' is Perl native encoding), which is why it was not noticed for such long time. utf8::valid(STRING) is an internal function that tests whether STRING is in a _consistent state_ regarding UTF-8. It returns true is well-formed UTF-8 and has the UTF-8 flag on _*or*_ if string is held as bytes (both these states are 'consistent'). For gitweb the second option was true, as output from git commands is opened without ':utf8' layer. What made it work at all for STRING in 'latin1' encoding is the fact that utf8:decode(STRING) turns on UTF-8 flag only if source string is valid UTF-8 and contains multi-byte UTF-8 characters... and that if string doesn't have UTF-8 flag set it is treated as in native Perl encoding, i.e. 'latin1' / 'iso-8859-1' (unless native encoding it is EBCDIC ;-)). It was ':utf8' layer that actually converted 'latin1' (no UTF-8 flag == native == 'latin1) to 'utf8'. Let's make use of the fact that utf8:decode(STRING) returns false if STRING is invalid as UTF-8 to check whether to enable fallback mode. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 12月, 2011 3 次提交
-
-
由 Jürgen Kreileder 提交于
Otherwise when javascript-actions are enabled gitweb shown broken author names in the tooltips on blame pages ('blame_incremental' view). Signed-off-by: NJürgen Kreileder <jk@blackdown.de> Acked-by: NJakub Narębski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jürgen Kreileder 提交于
This escapes the site name in OPML (XML uses the same escaping rules as HTML). Also fixes encoding issues because esc_html() uses to_utf8(). Signed-off-by: NJürgen Kreileder <jk@blackdown.de> Acked-by: NJakub Narębski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jürgen Kreileder 提交于
a) To fix the comparison with the chopped string, otherwise we compare bytes with characters, as chop_str() must run to_utf8() for correct operation b) To give the title attribute correct encoding; we need to mark strings as UTF-8 before outpur Signed-off-by: NJürgen Kreileder <jk@blackdown.de> Acked-by: NJakub Narębski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 11月, 2011 6 次提交
-
-
由 Kato Kazuyoshi 提交于
Add to the lower part of navigation bar (the action specific part) links allowing to switch between 'inline' (ordinary) diff and 'side by side' style diff. It is not shown for combined / compact combined diff. Signed-off-by: NKato Kazuyoshi <kato.kazuyoshi@gmail.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Use href(-replay->1,...) in (sub)navigation links (like changing style of view, or going to parent commit) so that extra options are preserved. This is needed so clicking on such (sub)navigation link would preserve style of diff; for example when using "side-by-side" diff style then going to parent commit would now also use this style. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Use separate background colors for pure removal, pure addition and change for side-by-side diff. This makes reading such diff easier, allowing to easily distinguish empty lines in diff from vertical whitespace used to align chunk blocks. Note that if lines in diff were numbered, the absence of line numbers [for one side] would help in distinguishing empty lines from vertical align. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Kato Kazuyoshi 提交于
This commits adds to support for showing "side-by-side" style diff. Currently you have to hand-craft the URL; navigation for selecting diff style is to be added in the next commit. The diff output in unified format from "git diff-tree" is reorganized to side-by-side style chunk by chunk with format_sidebyside_diff_chunk(). This reorganization requires knowledge about diff line classification, so format_diff_line() was renamed to process_diff_line(), and changed to return tuple (list) consisting of class of diff line and of HTML-formatted (but not wrapped in <div class="diff ...">...</div>) diff line. Wrapping is now done by caller, i.e. git_patchset_body(). Gitweb uses float+margin CSS-based layout for "side by side" diff. You can specify style of diff with "ds" ('diff_style') query parameter. Currently supported values are 'inline' and 'sidebyside'; the default is 'inline'. Another solution would be to use "opt" ('extra_options') for that... though current use of it in gitweb seems to suggest that "opt" is more about passing extra options to underlying git commands, and "git diff" doesn't support '--side-by-side' like GNU diff does, (yet?). Signed-off-by: NKato Kazuyoshi <kato.kazuyoshi@gmail.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Refactor main parts of HTML-formatting for diff chunk headers (formatting means here adding links and syntax hightlighting) into separate subroutines: * format_unidiff_chunk_header for ordinary diff, * format_cc_diff_chunk_header for combined diff (more than one parent) This makes format_diff_line() subroutine easier to follow. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Simplify classification of diff line body in format_diff_line(), replacing two long if-elsif chains (one for ordinary diff and one for combined diff of a merge commit) with a single regexp match. Refactor this code into diff_line_class() function. While at it: * Fix an artifact in that $diff_class included leading space to be able to compose classes like this "class=\"diff$diff_class\"', even when $diff_class was an empty string. This made code unnecessary ugly: $diff_class is now just class name or an empty string. * Introduce "ctx" class for context lines ($diff_class was set to "" in this case before this commit). Idea and initial code by Junio C Hamano, polish and testing by Jakub Narebski. Inspired by patch adding side-by-side diff by Kato Kazuyoshi, which required $diff_class to be name of class without extra space. Signed-off-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 10月, 2011 2 次提交
-
-
由 Julien Muchembled 提交于
This fixes a condition in filter_forks_from_projects_list that failed if process directory was different from project root: in such case, the subroutine was a no-op and forks were not detected. Signed-off-by: NJulien Muchembled <jm@jmuchemb.eu> Tested-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Lénaïc Huard 提交于
This allows web sites to add some specific html headers to the pages generated by gitweb. The new variable $site_html_head_string can be set to an html snippet that will be inserted at the end of the <head> section of each page generated by gitweb. Signed-off-by: NLénaïc Huard <lenaic@lhuard.fr.eu.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 9月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
The current code, as is, passes control characters, such as form-feed (^L) to highlight which then passes it through to the browser. User agents (web browsers) that support 'application/xhtml+xml' usually require that web pages declared as XHTML and with this mimetype are well-formed XML. Unescaped control characters cannot appear within a contents of a valid XML document. This will cause the browser to display one of the following warnings: * Safari v5.1 (6534.50) & Google Chrome v13.0.782.112: This page contains the following errors: error on line 657 at column 38: PCDATA invalid Char value 12 Below is a rendering of the page up to the first error. * Mozilla Firefox 3.6.19 & Mozilla Firefox 5.0: XML Parsing Error: not well-formed Location: http://path/to/git/repo/blah/blah Both errors were generated by gitweb.perl v1.7.3.4 w/ highlight 2.7 using arch/ia64/kernel/unwind.c from the Linux kernel. When syntax highlighter is not used, control characters are replaced by esc_html(), but with syntax highlighter they were passed through to browser (to_utf8() doesn't remove control characters). Introduce sanitize() subroutine which strips forbidden characters, but does not perform HTML escaping, and use it in git_blob() to sanitize syntax highlighter output for XHTML. Note that excluding "\t" (U+0009), "\n" (U+000A) and "\r" (U+000D) is not strictly necessary, atleast for currently the only callsite: "\t" tabs are replaced by spaces by untabify(), "\n" is stripped from each line before processing it, and replacing "\r" could be considered improvement. Originally-by: NChristopher M. Fuhrman <cfuhrman@panix.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 8月, 2011 1 次提交
-
-
由 张忠山 提交于
Otherwise the highlight filter would work on a corrupt byte sequence. Signed-off-by: N张忠山 <zzs213@126.com> Acked-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 8月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
"git config -z -l" that gitweb uses in git_parse_project_config() to populate %config hash returns section and key names of config variables in lowercase (they are case insensitive). When checking %config in git_get_project_config() we have to take it into account. Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 7月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
Because of backward compatibility we cannot change gitweb to always use /etc/gitweb.conf (i.e. even if gitweb_config.perl exists). For common system-wide settings we therefore need separate configuration file: /etc/gitweb-common.conf. Long description: gitweb currently obtains configuration from the following sources: 1. per-instance configuration file (default: gitweb_conf.perl) 2. system-wide configuration file (default: /etc/gitweb.conf) If per-instance configuration file exists, then system-wide configuration is _not used at all_. This is quite untypical and suprising behavior. Moreover it is different from way git itself treats /etc/git.conf. It reads in stuff from /etc/git.conf and then local repos can change or override things as needed. In fact this is quite beneficial, because it gives site admins a simple and easy way to give an automatic hint to a repo about things the admin would like. On the other hand changing current behavior may lead to the situation, where something in /etc/gitweb.conf may interfere with unintended interaction in the local repository. One solution would be to _require_ to do explicit include; with read_config_file() it is now easy, as described in gitweb/README (description introduced in this commit). But as J.H. noticed we cannot ask people to modify their per-instance gitweb config file to include system-wide settings, nor we can require them to do this. Therefore, as proposed by Junio, for gitweb to have centralized config elements while retaining backwards compatibility, introduce separate common system-wide configuration file, by default /etc/gitweb-common.conf Noticed-by: NDrew Northup <drew.northup@maine.edu> Helped-by: NJohn 'Warthog9' Hawley <warthog9@kernel.org> Inspired-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 7月, 2011 2 次提交
-
-
由 Jakub Narebski 提交于
Enhance usability of 'blob_plain' view protection against XSS attacks (enabled by setting $prevent_xss to true) by serving contents inline as safe 'text/plain' mimetype where possible, instead of serving with "Content-Disposition: attachment" to make sure they don't run in gitweb's security domain. This patch broadens downgrading to 'text/plain' further, to any */*+xml mimetype. This includes: application/xhtml+xml (*.xhtml, *.xht) application/atom+xml (*.atom) application/rss+xml (*.rss) application/mathml+xm (*.mathml) application/docbook+xml (*.docbook) image/svg+xml (*.svg, *.svgz) Probably most useful is serving XHTML files as text/plain in 'blob_plain' view, directly viewable. Because file with 'image/svg+xml' mimetype can be compressed SVGZ file, we have to check if */*+xml really is text file, via '-T $fd'. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
One of mechanism enabled by setting $prevent_xss to true is 'blob_plain' view protection. With XSS prevention on, blobs of all types except a few known safe ones are served with "Content-Disposition: attachment" to make sure they don't run in our security domain. Instead of serving text/* type files, except text/plain (and including text/html), as attachements, downgrade it to text/plain. This way HTML pages in 'blob_plain' (raw) view would be displayed in browser, but safely as a source, and not asked to be saved. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 6月, 2011 5 次提交
-
-
由 Jakub Narebski 提交于
Extract the following parts into separate subroutines: * finding correct MIME content type for HTML pages (text/html or application/xhtml+xml?) into get_content_type_html() * printing <link ...> elements in HTML head into print_header_links() * printing navigation "breadcrumbs" for given action into print_nav_breadcrumbs() * printing search form into print_search_form() This reduces git_header_html to two pages long (53 lines), making gitweb code easier to read. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Move git_header_html() and git_footer_html() invocation from git_search() to individual git_search_* subroutines. While at it, reorganize search-related code a bit, moving invoking of git commands before any output is generated. This has the following advantages: * gitweb now shows an error page if there was unknown search type (evaluate_and_validate_params checks only that it looks sanely); remember that we shouldn't call die_error after any output. * git_search_message is now safe agains die_error in parse_commits (though this is very unlikely). * gitweb now can check errors while invoking git commands and show error page (again, quite unlikely). Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Replace sequence of $foo .= "bar"; $foo .= "baz"; with $foo .= "bar" . "baz"; Use href(-replay=>1, -page=>undef) for first page of a multipl-page view. Wrap some lines to reduce their length. Some lines still have more than 80 characters, but lines are shorter now. No functional changes intended. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Create separate subroutines for handling each of aspects of searching the repository: * git_search_message ('commit', 'author', 'committer') * git_search_changes ('pickaxe') * git_search_content_of_files ('grep') Almost pure code movement (and unindent), which you can check e.g. via $ git blame -w --date=short -C -C HEAD^..HEAD -- gitweb/gitweb.perl | grep -C 3 -e '^[^^]' | less -S No functional changes intended. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Check first if relevant features: 'search', 'pickaxe', 'grep', as appropriate, are enabled before doing anything else in git_search. This should make git_search code more clear. While at it, expand a bit error message (e.g. 'Pickaxe' -> 'Pickaxe search'). Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 6月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
Both 'pickaxe' (searching changes) and 'grep' (searching files) require basic 'search' feature to be enabled to work. Enabling e.g. only 'pickaxe' won't work. Add a comment about this. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 6月, 2011 1 次提交
-
-
由 Ludwig Nussel 提交于
in openSUSE /etc/mime.types has only spaces. I don't know if there's a canonical reference that says that only tabs are allowed. Mutt at least also accepts spaces. So make gitweb more liberal too. Signed-off-by: NLudwig Nussel <ludwig.nussel@suse.de> Acked-by: NJakub Narebski <jnareb@gmail.com> Acked-by: NJohn 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 6月, 2011 1 次提交
-
-
由 Jonathan Nieder 提交于
v1.7.6-rc0~27^2~4 (gitweb: Change the way "content tags" ('ctags') are handled, 2011-04-29) tried to make gitweb's tag cloud feature more intuitive for webmasters by checking whether the ctags/<label> under a project's .git dir contains a number (representing the strength of association to <label>) before treating it as one. With that change, after putting '$feature{'ctags'}{'default'} = [1];' in your $GITWEB_CONFIG, you could do echo Linux >.git/ctags/linux and gitweb would treat that as a request to tag the current repository with the Linux tag, instead of the previous behavior of writing an error page embedded in the projects list that triggers error messages from Chromium and Firefox about malformed XML. Unfortunately the pattern (\d+) used to match numbers is too loose, and the "XML declaration allowed only at the start of the document" error can still be experienced if you write "Linux-2.6" in place of "Linux" in the example above. Fix it by tightening the pattern to ^\d+$. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 6月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
With XSS prevention on (enabled using $prevent_xss), blobs ('blob_plain') of all types except a few known safe ones are served with "Content-Disposition: attachment". However the check was too strict; it didn't take into account optional parameter attributes, media-type = type "/" subtype *( ";" parameter ) as described in RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 This fixes that, and it for example treats following as safe MIME media type: text/plain; charset=utf-8 Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 5月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
Beside being obvious reduction of duplicated code, this is enables us to easily call site-wide config file in per-installation config file. The actual update to documentation is left for next commit, because of possible exclusive alternative (possible other next commit) of always reading system-wide config file and relying on per-instalation config file overriding system-wide defaults. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Acked-by: NJohn 'Warthog9' Hawley <warthog9@kernel.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 5月, 2011 5 次提交
-
-
由 Jakub Narebski 提交于
Configure JavaScript-based ability to select common timezone for git dates via %feature mechanism, namely 'javascript-timezone' feature. The following settings are configurable: * default timezone (defaults to 'local' i.e. browser timezone); this also can function as a way to disable this ability, by setting it to false-ish value (undef or '') * name of cookie to store user's choice of timezone * class name to mark dates NOTE: This is a bit of abuse of %feature system, which can store only sequence of values, rather than dictionary (hash); usually but not always only a single value is used. Based-on-code-by: NJohn 'Warthog9' Hawley <warthog9@eaglescrag.net> Helped-by: NKevin Cernekee <cernekee@gmail.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 John 'Warthog9' Hawley 提交于
This will modify HTML, add CSS rules and add DOM event handlers so that clicking on any date (the common part, not the localtime part) will display a drop down menu to choose the timezone to change to. Currently menu displays only the following timezones: utc local -1200 -1100 ... +1100 +1200 +1300 +1400 In timezone selection menu each timezone is +1hr to the previous. The code is capable of handling fractional timezones, but those have not been added to the menu. All changes are saved to a cookie, so page changes and closing / reopening browser retains the last known timezone setting used. [jn: Changed from innerHTML to DOM, moved to event delegation for onclick to trigger menu, added close button and cookie refreshing] Helped-by: NKevin Cernekee <cernekee@gmail.com> Signed-off-by: NJohn 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 John 'Warthog9' Hawley 提交于
This patch is based on Kevin Cernekee's <cernekee@gmail.com> patch series entitled "gitweb: introduce localtime feature". While Kevin's patch changed the server side output so that the timezone was output from gitweb itself, this has a number of drawbacks, in particular with respect to gitweb-caching. This patch takes the same basic goal, display the appropriate times in a given common timezone, and implements it in JavaScript. This requires adding / using a new class, "datetime", to be able to find elements to be adjusted from JavaScript. Appropriate dates are wrapped in a span with this class. Timezone to be used can be retrieved from "gitweb_tz" cookie, though currently there is no way to set / manipulate this cookie from gitweb; this is left for later commit. Valid timezones, currently, are: "utc", "local" (which means that timezone is taken from browser), and "+/-ZZZZ" numeric timezone as in RFC-2822. Default timezone is "local" (currently not configurable, left for later commit). Fallback (should JavaScript not be enabled) is to treat dates as they have been and display them, only, in UTC. Pages affected: * 'summary' view, "last change" field (commit time from latest change) * 'log' view, author time * 'commit' and 'commitdiff' views, author/committer time * 'tag' view, tagger time Based-on-code-from: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: NJohn 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
format_timestamp_html loses its "-localtime => 1" option, and now always print the local time (in author/comitter/tagger local timezone), with "atnight" warning if needed. This means that both 'summary' and 'log' views now display localtime. In the case of 'log' view this can be thought as an improvement, as now one can easily see which commits in a series are made "atnight" and should be examined closer. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
It is pure refactoring and doesn't change gitweb output, though this could potentially affect 'summary', 'log', and 'commit'-like views ('commit', 'commitdiff', 'tag'). Remove print_local_time and format_local_time, as their use is now replaced (indirectly) by using format_timestamp_html. While at it improve whitespace formatting. Inspired-by-code-by: NKevin Cernekee <cernekee@gmail.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 4月, 2011 1 次提交
-
-
由 Jakub Narebski 提交于
Extract filtering out forks (which is done if 'forks' feature is enabled) into filter_forks_from_projects_list subroutine, and searching projects (via projects search form, or via content tags) into search_projects_list subroutine. Both are now run _before_ displaying projects, and not while printing; this allow to know upfront if there were any found projects. Gitweb now can and do print 'No such projects found' if user searches for phrase which does not correspond to any project (any repository). This also would allow splitting projects list into pages, if we so desire. Filtering out forks and marking repository (project) as having forks is now consolidated into one subroutine (special case of handling forks in git_get_projects_list only for $projects_list being file is now removed). Forks handling is also cleaned up and simplified. $pr->{'forks'} now contains un-filled list of forks; we can now also detect situation where the way for having forks is prepared, but there are no forks yet. Sorting projects got also refactored in a very straight way (just moving code) into sort_projects_list subroutine. The interaction between forks, content tags and searching is now made more explicit: searching whether by tag, or via search form turns off fork filtering (gitweb searches also forks, and will show all results). If 'ctags' feature is disabled, then searching by tag is too. The t9500 test now includes some basic test for 'forks' and 'ctags' features; the t9502 includes test checking if gitweb correctly filters out forks. Generating list of projects by scanning given directory is now also a bit simplified wrt. handling filtering; it is byproduct of extracting filtering forks to separate subroutine. While at it we now detect that there are no projects and respond with "404 No projects found" also for 'project_index' and 'opml' actions. Helped-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-