git/gitweb/static/js, branch maint

doc: switch links to https

2023-11-26T01:07:05Z

These sites offer https versions of their content. Using the https versions provides some protection for users. Signed-off-by: Josh Soref Signed-off-by: Junio C Hamano

doc: update links to current pages

2023-11-26T01:07:05Z

It's somewhat traditional to respect sites' self-identification. Signed-off-by: Josh Soref Signed-off-by: Junio C Hamano

gitweb: correctly store previous rev in javascript-actions mode

2019-10-28T02:06:57Z

Without this change, the setting $feature{'javascript-actions'}{'default'} = [1]; in gitweb.conf breaks gitweb's blame page: clicking on line numbers displayed in the second column on the page has no effect. For comparison, with javascript-actions disabled, clicking on line numbers loads the previous version of the line. Addresses https://bugs.debian.org/741883. Signed-off-by: Jonathan Nieder Signed-off-by: Robert Luberda Acked-by: Jakub Narębski Signed-off-by: Junio C Hamano

correct a few doubled-word nits in comments and documentation

2012-03-28T18:18:35Z

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 Signed-off-by: Junio C Hamano

Merge branch 'ps/gitweb-js-with-lineno'

2011-10-10T22:56:20Z

* ps/gitweb-js-with-lineno: gitweb: Fix links to lines in blobs when javascript-actions are enabled

gitweb: Fix links to lines in blobs when javascript-actions are enabled

2011-09-27T16:34:37Z

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 Acked-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb.js: use setTimeout rather than setInterval in blame_incremental.js

2011-05-27T18:00:42Z

If there is a possibility that your logic could take longer to execute than the interval time, it is recommended that you recursively call a named function using window.setTimeout rather than window.setInterval. Therefore instead of using setInterval as an alternate way of invoking handleResponse (because some web browsers call onreadystatechange only once per each distinct state, and not for each server flush), use setTimeout and reset it from handleResponse. As a bonus this allows us to get rid of timer if it turns out that web browser calls onreadystatechange on each server flush. While at it get rid of `xhr' global variable, creating it instead as local variable in startBlame and passing it as parameter, and of `pollTimer' global variable, passing it as member of xhr object (xhr.pollTimer). Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb.js: No need for loop in blame_incremental's handleResponse()

2011-05-27T18:00:39Z

JavaScript is single-threaded, so there is no need for protecting against changes to XMLHttpRequest object behind event handler back. Therefore there is no need for loop that was here in case `xhr' got new changes while processing current changes. This should make code a bit more clear. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb.js: No need for inProgress in blame_incremental.js

2011-05-27T18:00:35Z

JavaScript is single-threaded, so there is no need for protection against re-entrancy via inProgress variable. In particular calls to setInterval handler are stacked if handler doesn't finish before new interrupt (before new interval). The same happens with events - they are (hopefully) stacked if even handler didn't finish work. Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano

gitweb.js: Add UI for selecting common timezone to display dates

2011-05-24T18:22:45Z

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 Signed-off-by: John 'Warthog9' Hawley Signed-off-by: Jakub Narebski Signed-off-by: Junio C Hamano