kernel/git - git - PowerEL Git System

19212 Commits

6 Branches

36 Tags

131 MiB

Tree: 63267de2ac

Commit Graph

Author	SHA1	Message	Date
Jakub Narebski	c4ccf61f4c	gitweb: Create links leading to 'blame_incremental' using JavaScript The new 'blame_incremental' view requires JavaScript to run. Not all web browsers implement JavaScript (e.g. text browsers such as Lynx), and not all users have JavaScript enabled. Therefore instead of unconditionally linking to 'blame_incremental' view, we use JavaScript to convert those links to lead to view utilizing JavaScript, by adding 'js=1' to link. Currently the only action that takes 'js=1' into account is 'blame', which then acts as if it was called as 'blame_incremental' action. Possible enhancement would be to do JavaScript redirect by setting window.location instead of modifying $format and $action in git_blame_common() subroutine. The only JavaScript-aware/using view is currently 'blame_incremental'. While at it move reading JavaScript to git_footer_html() subroutine. Note that in this view we do not add 'js=1' currently (even though perhaps we should; note that for consistency we should also add 'js=1' in links added by JavaScript part of 'blame_incremental'). This idea was originally implemented by Petr Baudis in http://article.gmane.org/gmane.comp.version-control.git/47614 but it added <script> element with fixBlameLinks() function in page header, to be added as onload event using 'onload' attribute of HTML 'body' element: <body onload="fixBlameLinks();">. This version adds script at then end of page (in the page footer), and uses JavaScript 'window.onload=fixLinks();'. Also in Petr version only links marked with 'blamelink' class were modified, and they were modified by replacing "a=blame" by "a=blame_incremental"... which doesn't work for path_info links, and might replace wrong part if there is "a=blame" in project name, ref name or file name. Slightly different solution was implemented by Martin Koegler in http://thread.gmane.org/gmane.comp.version-control.git/47902/focus=47905 Here GitAddLinks() function was in gitweb.js file, not as contents of <script> element. It was also included in page header (in <head> element) though, which means waiting for a script to load (and run). It was smarter in that to "fix" (modify) link, it split URL, modified value of 'a' parameter, and then recreated modified link. It avoids trouble with "a=blame" as substring in project name or file name, but it doesn't work with path_info URL/link in the way it was written. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Jakub Narebski	e206d62a92	gitweb: Colorize 'blame_incremental' view during processing This requires using 3 colors, not only two, to choose a color that is different from colors of up to 2 neighbors. gitweb.js selects the least used color, if more than one color is possible. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Jakub Narebski	4af819d4ca	gitweb: Incremental blame (using JavaScript) Add 'blame_incremental' view, which uses "git blame --incremental" and JavaScript (Ajax), where 'blame' use "git blame --porcelain". * gitweb generates initial info by putting file contents (from "git cat-file") together with line numbers in blame table * then gitweb makes web browser JavaScript engine call startBlame() function from gitweb.js * startBlame() opens XMLHttpRequest connection to 'blame_data' view, which in turn calls "git blame --incremental" for a file, and streams output of git-blame to JavaScript (gitweb.js) * XMLHttpRequest event handler updates line info in blame view as soon as it gets data from 'blame_data' (from server), and it also updates progress info * when 'blame_data' ends, and gitweb.js finishes updating line info, it fixes colors to match (as far as possible) ordinary 'blame' view, and updates information about how long it took to generate page. Gitweb deals with streamed 'blame_data' server errors by displaying them in the progress info area (just in case). The 'blame_incremental' view tries to be equivalent to 'blame' action; there are however a few differences in output between 'blame' and 'blame_incremental' view: * 'blame_incremental' always used query form for this part of link(s) which is generated by JavaScript code. The difference is visible if we use path_info link (pass some or all arguments in path_info). Changing this would require implementing something akin to href() subroutine from gitweb.perl in JavaScript (in gitweb.js). * 'blame_incremental' always uses "rowspan" attribute, even if rowspan="1". This simplifies code, and is not visible to user. * The progress bar and progress info are still there even after JavaScript part of 'blame_incremental' finishes work. Note that currently no link generated by gitweb leads to this new view. This code is based on patch by Petr Baudis <pasky@suse.cz> patch, which in turn was tweaked up version of Fredrik Kuivinen <frekui@gmail.com>'s proof of concept patch. This patch adds GITWEB_JS compile configuration option, and modifies git-instaweb.sh to take gitweb.js into account. The code for git-instaweb.sh was taken from Pasky's patch. Signed-off-by: Fredrik Kuivinen <frekui@gmail.com> Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago

Author

SHA1

Message

Date

Jakub Narebski

c4ccf61f4c

gitweb: Create links leading to 'blame_incremental' using JavaScript

The new 'blame_incremental' view requires JavaScript to run.  Not all
web browsers implement JavaScript (e.g. text browsers such as Lynx),
and not all users have JavaScript enabled.  Therefore instead of
unconditionally linking to 'blame_incremental' view, we use JavaScript
to convert those links to lead to view utilizing JavaScript, by adding
'js=1' to link.

Currently the only action that takes 'js=1' into account is 'blame',
which then acts as if it was called as 'blame_incremental' action.
Possible enhancement would be to do JavaScript redirect by setting
window.location instead of modifying $format and $action in
git_blame_common() subroutine.

The only JavaScript-aware/using view is currently 'blame_incremental'.
While at it move reading JavaScript to git_footer_html() subroutine.
Note that in this view we do not add 'js=1' currently (even though
perhaps we should; note that for consistency we should also add 'js=1'
in links added by JavaScript part of 'blame_incremental').

This idea was originally implemented by Petr Baudis in
  http://article.gmane.org/gmane.comp.version-control.git/47614
but it added <script> element with fixBlameLinks() function in page
header, to be added as onload event using 'onload' attribute of HTML
'body' element: <body onload="fixBlameLinks();">.  This version adds
script at then end of page (in the page footer), and uses JavaScript
'window.onload=fixLinks();'.  Also in Petr version only links marked
with 'blamelink' class were modified, and they were modified by
replacing "a=blame" by "a=blame_incremental"... which doesn't work for
path_info links, and might replace wrong part if there is "a=blame" in
project name, ref name or file name.

Slightly different solution was implemented by Martin Koegler in
  http://thread.gmane.org/gmane.comp.version-control.git/47902/focus=47905
Here GitAddLinks() function was in gitweb.js file, not as contents of
<script> element.  It was also included in page header (in <head>
element) though, which means waiting for a script to load (and run).
It was smarter in that to "fix" (modify) link, it split URL, modified
value of 'a' parameter, and then recreated modified link.  It avoids
trouble with "a=blame" as substring in project name or file name, but
it doesn't work with path_info URL/link in the way it was written.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

16 years ago

Jakub Narebski

e206d62a92

gitweb: Colorize 'blame_incremental' view during processing

This requires using 3 colors, not only two, to choose a color that is
different from colors of up to 2 neighbors.

gitweb.js selects the least used color, if more than one color is
possible.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

16 years ago

Jakub Narebski

4af819d4ca

gitweb: Incremental blame (using JavaScript)

Add 'blame_incremental' view, which uses "git blame --incremental"
and JavaScript (Ajax), where 'blame' use "git blame --porcelain".

 * gitweb generates initial info by putting file contents (from
   "git cat-file") together with line numbers in blame table
 * then gitweb makes web browser JavaScript engine call startBlame()
   function from gitweb.js
 * startBlame() opens XMLHttpRequest connection to 'blame_data' view,
   which in turn calls "git blame --incremental" for a file, and
   streams output of git-blame to JavaScript (gitweb.js)
 * XMLHttpRequest event handler updates line info in blame view as soon
   as it gets data from 'blame_data' (from server), and it also updates
   progress info
 * when 'blame_data' ends, and gitweb.js finishes updating line info,
   it fixes colors to match (as far as possible) ordinary 'blame' view,
   and updates information about how long it took to generate page.

Gitweb deals with streamed 'blame_data' server errors by displaying
them in the progress info area (just in case).

The 'blame_incremental' view tries to be equivalent to 'blame' action;
there are however a few differences in output between 'blame' and
'blame_incremental' view:

 * 'blame_incremental' always used query form for this part of link(s)
   which is generated by JavaScript code.  The difference is visible
   if we use path_info link (pass some or all arguments in path_info).
   Changing this would require implementing something akin to href()
   subroutine from gitweb.perl in JavaScript (in gitweb.js).
 * 'blame_incremental' always uses "rowspan" attribute, even if
   rowspan="1".  This simplifies code, and is not visible to user.
 * The progress bar and progress info are still there even after
   JavaScript part of 'blame_incremental' finishes work.

Note that currently no link generated by gitweb leads to this new view.

This code is based on patch by Petr Baudis <pasky@suse.cz> patch, which
in turn was tweaked up version of Fredrik Kuivinen <frekui@gmail.com>'s
proof of concept patch.

This patch adds GITWEB_JS compile configuration option, and modifies
git-instaweb.sh to take gitweb.js into account.  The code for
git-instaweb.sh was taken from Pasky's patch.

Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

16 years ago

3 Commits (63267de2acc18027fc0208c0937fd62b91301fec)