Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
Jim Meyering 65c2b2b509 correct a few doubled-word nits in comments and documentation
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-28 11:18:35 -07:00
Junio C Hamano 59b32ff338 Merge branch 'ps/gitweb-js-with-lineno'
* ps/gitweb-js-with-lineno:
  gitweb: Fix links to lines in blobs when javascript-actions are enabled
2011-10-10 15:56:20 -07:00
Peter Stuge 2b07ff3ffa gitweb: Fix links to lines in blobs when javascript-actions are enabled
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-09-27 09:34:37 -07:00
Jakub Narebski 42ab5d40de gitweb.js: use setTimeout rather than setInterval in blame_incremental.js
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-27 11:00:42 -07:00
Jakub Narebski e8dd0e4063 gitweb.js: No need for loop in blame_incremental's handleResponse()
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-27 11:00:39 -07:00
Jakub Narebski 4510165934 gitweb.js: No need for inProgress in blame_incremental.js
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 <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-27 11:00:35 -07:00
John 'Warthog9' Hawley 2ae8da2552 gitweb.js: Add UI for selecting common timezone to display dates
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-24 11:22:45 -07:00
John 'Warthog9' Hawley 291e52bd19 gitweb: JavaScript ability to adjust time based on timezone
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-24 11:22:45 -07:00
Jakub Narebski 1cae3ee70d gitweb.js: Provide getElementsByClassName method (if it not exists)
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-24 11:22:45 -07:00
Jakub Narebski 9a86dd5710 gitweb: Split JavaScript for maintability, combining on build
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-24 11:22:44 -07:00
Jakub Narebski fcce886bfb gitweb.js: Introduce code to handle cookies from JavaScript
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-24 11:22:44 -07:00
Jakub Narebski 54b1479a77 gitweb.js: Extract and improve datetime handling
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-24 11:22:44 -07:00
Jakub Narebski 4dfa207eec gitweb.js: Provide default values for padding in padLeftStr and padLeft
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-24 11:22:44 -07:00
Jakub Narebski e2895de4d8 gitweb.js: Update and improve comments in JavaScript files
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-24 11:22:44 -07:00