summaryrefslogtreecommitdiff
path: root/gitweb
AgeCommit message (Collapse)AuthorFilesLines
2011-10-26Merge branch 'ps/gitweb-js-with-lineno' into maint-1.7.6Libravatar Junio C Hamano1-4/+4
* ps/gitweb-js-with-lineno: gitweb: Fix links to lines in blobs when javascript-actions are enabled
2011-09-27gitweb: Fix links to lines in blobs when javascript-actions are enabledLibravatar Peter Stuge1-4/+4
The fixLinks() function adds 'js=1' to each link that does not already have 'js' query parameter specified. This is used to signal to gitweb that the browser can actually do javascript when these links are used. There are two problems with the existing code: 1. URIs with fragment and 'js' query parameter, like e.g. ...foo?js=0#l199 were not recognized as having 'js' query parameter already. 2. The 'js' query parameter, in the form of either '?js=1' or ';js=1' was appended at the end of URI, even if it included a fragment (had a hash part). This lead to the incorrect links like this ...foo#l199?js=1 instead of adding query parameter as last part of query, but before the fragment part, i.e. ...foo?js=1#l199 Signed-off-by: Peter Stuge <peter@stuge.se> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-16Merge branch 'jn/mime-type-with-params' into maintLibravatar Junio C Hamano1-1/+10
* jn/mime-type-with-params: gitweb: Serve */*+xml 'blob_plain' as text/plain with $prevent_xss gitweb: Serve text/* 'blob_plain' as text/plain with $prevent_xss
2011-06-30gitweb: Serve */*+xml 'blob_plain' as text/plain with $prevent_xssLibravatar Jakub Narebski1-1/+2
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: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-30gitweb: Serve text/* 'blob_plain' as text/plain with $prevent_xssLibravatar Jakub Narebski1-1/+9
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: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-21Merge branch 'maint'Libravatar Junio C Hamano1-0/+2
* maint: gitweb: 'pickaxe' and 'grep' features requires 'search' to be enabled
2011-06-21gitweb: 'pickaxe' and 'grep' features requires 'search' to be enabledLibravatar Jakub Narebski1-0/+2
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: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-09gitweb: do not misparse nonnumeric content tag files that contain a digitLibravatar Jonathan Nieder1-1/+1
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: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-06Merge branch 'jn/mime-type-with-params'Libravatar Junio C Hamano1-1/+1
* jn/mime-type-with-params: gitweb: Fix usability of $prevent_xss
2011-06-05gitweb: Fix usability of $prevent_xssLibravatar Jakub Narebski1-1/+1
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: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-03gitweb: Move "Requirements" up in gitweb/INSTALLLibravatar Jakub Narebski1-15/+15
This way you can examine prerequisites at first glance, before detailed instructions on installing gitweb. Straightforward text movement. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-02gitweb: Describe CSSMIN and JSMIN in gitweb/INSTALLLibravatar Jakub Narebski1-6/+13
The build-time configuration variables JSMIN and CSSMIN were mentioned only in Makefile; add their description to gitweb/INSTALL. This required moving description of GITWEB_JS up, near GITWEB_CSS and just introduced CSMIN and JSMIN. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-02gitweb: Move information about installation from README to INSTALLLibravatar Jakub Narebski2-116/+113
Almost straightformard moving of "How to configure gitweb for your local system" section from gitweb/README to gitweb/INSTALL, as it is about build time configuration. Updated references to it. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26Merge branch 'jn/gitweb-js'Libravatar Junio C Hamano10-241/+1022
* jn/gitweb-js: gitweb: Make JavaScript ability to adjust timezones configurable gitweb.js: Add UI for selecting common timezone to display dates gitweb: JavaScript ability to adjust time based on timezone gitweb: Unify the way long timestamp is displayed gitweb: Refactor generating of long dates into format_timestamp_html gitweb.js: Provide getElementsByClassName method (if it not exists) gitweb.js: Introduce code to handle cookies from JavaScript gitweb.js: Extract and improve datetime handling gitweb.js: Provide default values for padding in padLeftStr and padLeft gitweb.js: Update and improve comments in JavaScript files gitweb: Split JavaScript for maintability, combining on build
2011-05-26Merge branch 'jn/ctags-more'Libravatar Junio C Hamano3-46/+144
* jn/ctags-more: gitweb: Optional grouping of projects by category gitweb: Modularized git_get_project_description to be more generic gitweb: Split git_project_list_body in two functions
2011-05-25gitweb: Refactor reading and parsing config file into read_config_fileLibravatar Jakub Narebski1-8/+20
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: Jakub Narebski <jnareb@gmail.com> Acked-by: John 'Warthog9' Hawley <warthog9@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb: Make JavaScript ability to adjust timezones configurableLibravatar Jakub Narebski1-8/+31
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: John 'Warthog9' Hawley <warthog9@eaglescrag.net> Helped-by: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb.js: Add UI for selecting common timezone to display datesLibravatar John 'Warthog9' Hawley4-16/+345
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: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb: JavaScript ability to adjust time based on timezoneLibravatar John 'Warthog9' Hawley4-3/+84
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: John 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb: Unify the way long timestamp is displayedLibravatar Jakub Narebski1-5/+3
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: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb: Refactor generating of long dates into format_timestamp_htmlLibravatar Jakub Narebski1-23/+22
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: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb.js: Provide getElementsByClassName method (if it not exists)Libravatar Jakub Narebski1-0/+51
The code is simplified and does not support full specification of native getElementsByClassName method, but implements just subset that would be enough for gitweb, supporting only single class name. Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb: Split JavaScript for maintability, combining on buildLibravatar Jakub Narebski5-206/+268
Split originally single gitweb.js file into smaller files, each dealing with single issue / area of responsibility. This move should make gitweb's JavaScript code easier to maintain. For better webapp performance it is recommended[1][2][3] to combine JavaScript files. Do it during build time (in gitweb/Makefile), by straight concatenation of files into gitweb.js file (which is now ignored as being generated). This means that there are no changes to gitweb script itself - it still uses gitweb.js or gitweb.min.js, but now generated. [1]: http://developer.yahoo.com/performance/rules.html "Minimize HTTP Requests" section [2]: http://code.google.com/speed/articles/include-scripts-properly.html "1. Combine external JavaScript files" [3]: http://javascript-reference.info/speed-up-your-javascript-load-time.htm "Combine Your Files" section. See also new gitweb/static/js/README file. Inspired-by-patch-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb.js: Introduce code to handle cookies from JavaScriptLibravatar Jakub Narebski2-0/+115
Introduced gitweb/static/js/cookies.js file provides functions for setting, getting and deleting cookies. Code taken from subsection "Cookies in JavaScript" of "Professional JavaScript for Web Developers" by Nicholas C. Zakas and from cookie plugin for jQuery (dual licensed under the MIT and GPL licenses). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb.js: Extract and improve datetime handlingLibravatar Jakub Narebski3-51/+162
Move formatDateISOLocal(epoch, timezone) function (and also helper timezoneOffset(timezoneInfo) function it requires) from common-lib.js to datetime.js Add new functions: * localTimezoneOffset - to get browser timezone offset in seconds * localTimezoneInfo - to get browser timezone in '(+|-)HHMM' format * formatTimezoneInfo - turn offset in hours and minutes into '(+|-)HHMM' * parseRFC2822Date - to parse RFC-2822 dates that gitweb uses into epoch * formatDateRFC2882 - like formatDateISOLocal, only RFC-2822 format All those functions are meant to be used in future commit 'gitweb: javascript ability to adjust time based on timezone' An alternative would be to use e.g. Datejs (http://www.datejs.com) library, or JavaScript framework that has date formatting (perhaps as a plugin). While at it escape '-' in character class inside tzRe regexp, as recommended by JSLint (http://www.jslint.com). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb.js: Provide default values for padding in padLeftStr and padLeftLibravatar Jakub Narebski1-3/+11
This means that one can use padLeft(4, 2) and it would be equivalent to runing padLeft(4, 2, '0'), and it would return '04' i.e. '4' padded with '0' to width 2, to be used e.g. in formatting date and time. This should make those functions easier to use. Current code doesn't yet make use of this feature. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24gitweb.js: Update and improve comments in JavaScript filesLibravatar Jakub Narebski2-15/+19
This consists of adding a few extra explanation, fixing descriptions of functions to match names of parameters in code, adding a few separators, and fixing spelling -- while at it spell 'neighbor' using American spelling (and not as 'neighbour'). This is post-split cleanup. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-11Merge branch 'jn/ctags'Libravatar Junio C Hamano1-121/+276
* jn/ctags: gitweb: Mark matched 'ctag' / contents tag (?by_tag=foo) gitweb: Change the way "content tags" ('ctags') are handled gitweb: Restructure projects list generation
2011-04-29gitweb: Optional grouping of projects by categoryLibravatar Sebastien Cevey3-3/+82
This adds the $projects_list_group_categories option which, if enabled, will result in grouping projects by category on the project list page. The category is specified for each project by the $GIT_DIR/category file or the 'gitweb.category' variable in its configuration file. By default, projects are put in the $project_list_default_category category. Note: - Categories are always sorted alphabetically, with projects in each category sorted according to the globally selected $order. - When displaying a subset of all the projects (page limiting), the category headers are only displayed for projects present on the page. The feature is inspired from Sham Chukoury's patch for the XMMS2 gitweb, but has been rewritten for the current gitweb code. The CSS for categories is inspired from Gustavo Sverzut Barbieri's patch to group projects by path. Thanks to Florian Ragwitz for Perl tips. [jn: Updated to post restructuring projects list generation, fixed bugs, added very basic test in t9500 that there are no warnings from Perl.] Signed-off-by: Sebastien Cevey <seb@cine7.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29gitweb: Mark matched 'ctag' / contents tag (?by_tag=foo)Libravatar Jakub Narebski1-3/+9
It might have been hard to discover that current view is limited to projects with given content tag (ctag), as it was distinquished only in gitweb URL. Mark matched contents tag in the tag cloud using "match" class, for easier discovery. This commit introduces a bit of further code duplication in git_populate_project_tagcloud(). Signed-off-by: Jakub Narebski <jnareb@gmail.com> Acked-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29gitweb: Modularized git_get_project_description to be more genericLibravatar Sebastien Cevey1-8/+16
Introduce a git_get_file_or_project_config utility function to retrieve a repository variable either from a plain text file in the $GIT_DIR or else from 'gitweb.$variable' in the repository config (e.g. 'description'). This would be used in next commit to retrieve category for a project, which is to be stored in the same way as project description. Signed-off-by: Sebastien Cevey <seb@cine7.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29gitweb: Change the way "content tags" ('ctags') are handledLibravatar Jakub Narebski1-44/+97
The major change is removing the ability to edit content tags (ctags) in a web browser. The interface was created by gitweb, while actual editing of tags was to be done by external script; the API was not defined, and neither was provided example implementation. Such split is also a bit fragile - interface and implementation have to be kept in sync. Gitweb provided only ability to add tags; you could not edit tags nor delete them. Format of ctags is now described in the comment above git_get_project_ctags subroutine. Gitweb now is more robust with respect to original ctags format; it also accepts two new formats: $GIT_DIR/ctags file, with one content tag per line, and multi-value `gitweb.ctag' config variable. Gathering all ctags of all project is now put in git_gather_all_ctags subroutine, making git_project_list_body more clear. git_populate_project_tagcloud subroutine now generates data used for tag cloud, including generation of ctag link, also in the case HTML::TagCloud module is unavailable. Links are now generated using href() subroutine - this is more robust, as ctags might contain '?', ';' and '=' special characters that need to be escaped in query param. Shown tags are HTML-escaped. The generation of tag cloud in git_show_project_tagcloud in the case when HTML::TagCloud is not available is now changed slightly. The 'content tags' field on project summary page is made more in line with other fields in "projects_list" table. Because one cannot now add new tags from web interface, this field is no longer displayed when there are no content tags for given project. Ctags-issue-Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Ctags-issue-Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29gitweb: Split git_project_list_body in two functionsLibravatar Sebastien Cevey1-39/+50
Extract the printing of project rows (body/contents of projects list table) on the 'project_list' page into a separate git_project_list_rows function. This makes it easier to reuse the code to print different subsets of the whole project list. [jn: Updated to post restructuring projects list generation] Signed-off-by: Sebastien Cevey <seb@cine7.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29gitweb: Restructure projects list generationLibravatar Jakub Narebski1-77/+173
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: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-26gitweb: supply '-n' to gzip for identical outputLibravatar Fraser Tweedale1-1/+1
For projects that do not release official archives, gitweb's snapshot feature would be an excellent alternative, and but without the '-n' ('--no-name') argument, gzip includes a timestamp in output which results in different files. Because some systems hash/checksum downloaded files to ensure integrity of the tarball (e.g FreeBSD), it is desirable to produce tarballs in a reproducible way for that purpose. Whilst '--no-name' is more descriptive, the long version of the flag is not supported on all systems. In particular, OpenBSD does not appear to support it. Supply '-n' to gzip to exclude timestamp from output and produce idential output every time. Signed-off-by: Fraser Tweedale <frase@frase.id.au> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13remove doubled words, e.g., s/to to/to/, and fix related typosLibravatar Jim Meyering1-1/+1
I found that some doubled words had snuck back into projects from which I'd already removed them, so now there's a "syntax-check" makefile rule in gnulib to help prevent recurrence. Running the command below spotted a few in git, too: git ls-files | xargs perl -0777 -n \ -e 'while (/\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt])\s+\1\b/gims)' \ -e '{$n=($` =~ tr/\n/\n/ + 1); ($v=$&)=~s/\n/\\n/g;' \ -e 'print "$ARGV:$n:$v\n"}' Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-04Merge branch 'maint'Libravatar Junio C Hamano1-5/+19
* maint: Documentation: trivial grammar fix in core.worktree description gitweb: Fix parsing of negative fractional timezones in JavaScript
2011-04-04gitweb: Fix parsing of negative fractional timezones in JavaScriptLibravatar Jakub Narebski1-5/+19
Extract converting numerical timezone in the form of '(+|-)HHMM' to timezoneOffset function, and fix parsing of negative fractional timezones. This is used to format timestamps in 'blame_incremental' view; this complements commit 2b1e172 (gitweb: Fix handling of fractional timezones in parse_date, 2011-03-25). Now gitweb.cgi/git.git/blame_incremental/3fe5489:/contrib/gitview/gitview#l853 and gitweb.cgi/git.git/blame/3fe5489:/contrib/gitview/gitview#l853 show the same correct time in author's local timezone in title (on mouseover) [Aneesh Kumar K.V, 2006-02-24 00:59:42 +0530]. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-25Sync with 1.7.4.2Libravatar Junio C Hamano1-2/+4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-25gitweb: Fix handling of fractional timezones in parse_dateLibravatar Jakub Narebski1-2/+4
Fractional timezones, like -0330 (NST used in Canada) or +0430 (Afghanistan, Iran DST), were not handled properly in parse_date; this means values such as 'minute_local' and 'iso-tz' were not generated correctly. This was caused by two mistakes: * sign of timezone was applied only to hour part of offset, and not as it should be also to minutes part (this affected only negative fractional timezones). * 'int $h + $m/60' is 'int($h + $m/60)' and not 'int($h) + $m/60', so fractional part was discarded altogether ($h is hours, $m is minutes, which is always less than 60). Note that positive fractional timezones +0430, +0530 and +1030 can be found as authortime in git.git repository itself. For example http://repo.or.cz/w/git.git/commit/88d50e7 had authortime of "Fri, 8 Jan 2010 18:48:07 +0000 (23:48 +0530)", which is not marked with 'atnight', when "git show 88d50e7" gives correct author date of "Sat Jan 9 00:18:07 2010 +0530". Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-23Merge branch 'kc/gitweb-pathinfo-w-anchor'Libravatar Junio C Hamano1-7/+20
* kc/gitweb-pathinfo-w-anchor: gitweb: fix #patchNN anchors when path_info is enabled
2011-03-19gitweb: Always call parse_date with timezone parameterLibravatar Jakub Narebski1-3/+2
Timezone is required to correctly set local time, which would be needed for future 'localtime' feature. While at it, remove unnecessary call to the function from git_log_body, as its return value is not used anywhere. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-18gitweb: fix #patchNN anchors when path_info is enabledLibravatar Kevin Cernekee1-7/+20
When $feature{'pathinfo'} is used, gitweb script sets the base URL to itself, so that relative links to static files work correctly. It does it by adding something like below to HTML head: <base href="http://HOST/gitweb.cgi"> This breaks the "patch" anchor links seen on the commitdiff pages, because these links, being relative (<a href="#patch1">), are resolved (computed) relative to the base URL and not relative to current URL, i.e. as: http://HOST/gitweb.cgi#patch1 Instead, they should look like this: http://HOST/gitweb.cgi/myproject.git/commitdiff/35a9811ef9d68eae9afd76bede121da4f89b448c#patch1 Add an "-anchor" parameter to href(), and use href(-anchor=>"patch1") to generate "patch" anchor links, so that the full path is included in the patch link. While at it, convert print "foo"; print "bar"; to print "foo" . "bar"; in the neighborhood of changes. Signed-off-by: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-16gitweb: highlight: replace tabs with spacesLibravatar Kevin Cernekee1-1/+1
Consider the following code fragment: /* * test */ vim ":set list" mode shows that the first character on each line is a tab: ^I/*$ ^I * test$ ^I */$ By default, the "highlight" program will retain the tabs in the HTML output: $ highlight --fragment --syntax c test.c <span class="hl com">/*</span> <span class="hl com"> * test</span> <span class="hl com"> */</span> vim list mode: ^I<span class="hl com">/*</span>$ <span class="hl com">^I * test</span>$ <span class="hl com">^I */</span>$ In gitweb, this winds up looking something like: 1 /* 2 * test 3 */ I tried both Firefox and Opera and saw the same behavior. The desired output is: 1 /* 2 * test 3 */ This can be accomplished by specifying "--replace-tabs=8" on the highlight command line. Signed-off-by: Kevin Cernekee <cernekee@gmail.com> Acked-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21gitweb/gitweb.perl: don't call S_ISREG() with undefLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change S_ISREG($to_mode_oct) to S_ISREG($from_mode_oct) in the branch that handles from modes, not to modes. This logic appears to have been caused by copy/paste programming by Jakub Narebski in e8e41a93. It would be better to rewrite this code not to be duplicated, but I haven't done so. This issue caused a failing test on perl 5.13.9, which has a warning that turned this up: gitweb.perl: Use of uninitialized value in subroutine entry at /home/avar/g/git/t/../gitweb/gitweb.perl line 4415. Which caused the Git test suite to fail on this test: ./t9500-gitweb-standalone-no-errors.sh (Wstat: 256 Tests: 90 Failed: 84) Failed tests: 1-8, 10-36, 38-45, 47-48, 50-88 Non-zero exit status: 1 Reported-by: perl 5.13.9 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21gitweb/gitweb.perl: remove use of qw(...) as parenthesesLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Using the qw(...) construct as implicit parentheses was deprecated in perl 5.13.5. Change the relevant code in gitweb to not use the deprecated construct. The offending code was introduced in 3562198b by Jakub Narebski. The issue is that perl will now warn about this: $ perl -wE 'for my $i qw(a b) { say $i }' Use of qw(...) as parentheses is deprecated at -e line 1. a b This caused gitweb.perl to warn on perl 5.13.5 and above, and these tests to fail on those perl versions: ./t9501-gitweb-standalone-http-status.sh (Wstat: 256 Tests: 11 Failed: 10) Failed tests: 2-11 Non-zero exit status: 1 ./t9502-gitweb-standalone-parse-output.sh (Wstat: 256 Tests: 10 Failed: 9) Failed tests: 2-10 Non-zero exit status: 1 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-07gitweb: Mention optional Perl modules in INSTALLLibravatar Jakub Narebski1-0/+6
Some optional additional Perl modules are required for some of extra features. Mention those in gitweb/INSTALL. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-27Don't pass "--xhtml" to hightlight in gitweb.perl script.Libravatar Adam Tkac1-1/+1
The "--xhtml" option is supported only in highlight < 3.0. There is no option to enforce (X)HTML output format compatible with both highlight < 3.0 and highlight >= 3.0. However default output format is HTML so we don't need to explicitly specify it. Signed-off-by: Adam Tkac <atkac@redhat.com> Helped-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-13Merge branch 'jn/gitweb-no-logo'Libravatar Junio C Hamano1-4/+9
* jn/gitweb-no-logo: gitweb: make logo optional
2011-01-04gitweb: remove unnecessary test when closing file descriptorLibravatar Sylvain Rabot1-2/+1
It happens that closing file descriptor fails whereas the blob is perfectly readable. According to perlman the reasons could be: If the file handle came from a piped open, "close" will additionally return false if one of the other system calls involved fails, or if the program exits with non-zero status. (If the only problem was that the program exited non-zero, $! will be set to 0.) Closing a pipe also waits for the process executing on the pipe to complete, in case you want to look at the output of the pipe afterwards, and implicitly puts the exit status value of that command into $?. Prematurely closing the read end of a pipe (i.e. before the process writ- ing to it at the other end has closed it) will result in a SIGPIPE being delivered to the writer. If the other end can't handle that, be sure to read all the data before closing the pipe. In this case we don't mind that close fails. Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>