git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFC] gitweb: Incremental blame - suggestions for improvements

From
Jakub Narebski <jnareb@gmail.com>
Date
Dec 14, 2008, 16:11 UTC
Message-ID
<m34p16eny3.fsf_-_@localhost.localdomain>
In-Reply-To
<1229213850-12787-1-git-send-email-jnareb@gmail.com>
A few suggestions for further improvement of blame_incremental:
 * Better support for data mining in 'blame_incremental' view,
   (for "lineno" links to (approximately) lead to previous version of
   line) would probably require for gitweb to accept "<rev>^" for 'hb'
   parameter (and perhaps resolve/parse it before saving to
   $hash_base). This would also help performance of 'blame' view.
 * Move some of processing to server, to 'blame_data' action, and for
   example send whole saved and processed info for a group of lines as
   JSON or as variation of "git blame --incremental" output.
 * Better error checking: not only check if scripting is turned on,
   but also if required methods like document.getElementById are
   available. Probably would require falback to *ugh* document.write.
 * Perhaps fallback on (slower) DOM methods if innerHTML is not
   available or doesn't work, which is the case for some versions of
   some browsers in strict XHTML (application/xml+html + XHTML DTD)
   mode.
 * Fallback on DOM Core methods of deleting cell if DOM HTML
   deleteCell method is not available; check that DOM Core way does
   not lead to memory leaks (by deleting element, but not its
   children).
 * Use 'one second spotlight' or other similar user interface patter
   to signal in more visible way than reaching 100% in progress info,
   and changing colors from 3-coloring to 2-color zebra in blame table
   that all blame data was received and entered.
 * Check in handleResponse if browser calls it on [each] server flush,
   by checking if it is called more than once with http.readyState == 3
   and with different http.responseText, and disable poll timer then.
 * Mark boundary commits (this applies both to 'blame' and
   'blame_incremental' views), using UNDOCUMENTED "boundary" header.
 * A toy. Make progress bar indicator more smooth by interpolating
   changes between updates, so it moves smoothly. This would make it
   provide impression for user, not an accurate measure of blamed
   percentage.
 * A toy. Make sure that 3-coloring during updating blame table use
   all three colors with similar frequency, for example by using the
   following implementation of chooseColorNoFrom function:
    // return one of given possible colors
    // example: chooseColorNoFrom(2, 3) might be 2 or 3
    var colorsFreq = [0, 0, 0];
    // assumes that  1 <= arguments[i] <= colorsFreq.length
    function chooseColorNoFrom() {
    	// choose the color which is least used
    	var colorNo = arguments[0];
    	for (var i = 1; i < arguments.length; i++) {
    		if (colorsFreq[arguments[i]-1] < colorsFreq[colorNo-1]) {
    			colorNo = arguments[i];
    		}
    	}
    	colorsFreq[colorNo-1]++;
    	return colorNo;
    }

Do you have your own suggestions? Comments? Would incremental blame help git-instaweb use?

-- 
Jakub Narebski
Poland
ShadeHawk on #git
Previous: Jakub Narebski
Message 31 of 31 in “gitweb: Improve git_blame in preparation for incremental blame”
  1. 0/3 gitweb: Improve git_blame in preparation for incremental blameJakub Narebski, Dec 9, 2008
  2. 1/3 gitweb: Move 'lineno' id from link to row element in git_blameJakub Narebski, Dec 9, 2008
  3. Luben TuikovDec 10, 2008
  4. Petr BaudisDec 17, 2008
  5. 2/3 gitweb: Cache $parent_commit info in git_blame()Jakub Narebski, Dec 9, 2008
  6. Nanako ShiraishiDec 10, 2008
  7. Jakub NarebskiDec 10, 2008
  8. Junio C HamanoDec 10, 2008
  9. 2/3 gitweb: Cache $parent_commit info in git_blame()Jakub Narebski, Dec 11, 2008
  10. Luben TuikovDec 11, 2008
  11. Junio C HamanoDec 11, 2008
  12. Junio C HamanoDec 12, 2008
  13. Jakub NarebskiDec 12, 2008
  14. Petr BaudisDec 17, 2008
  15. Junio C HamanoDec 17, 2008
  16. Luben TuikovDec 10, 2008
  17. Jakub NarebskiDec 10, 2008
  18. Luben TuikovDec 10, 2008
  19. Jakub NarebskiDec 10, 2008
  20. Luben TuikovDec 10, 2008
  21. 3/3 gitweb: A bit of code cleanup in git_blame()Jakub Narebski, Dec 9, 2008
  22. Jakub NarebskiDec 10, 2008
  23. Junio C HamanoDec 10, 2008
  24. Luben TuikovDec 10, 2008
  25. 4/3 gitweb: Incremental blame (proof of concept)Jakub Narebski, Dec 10, 2008
  26. Junio C HamanoDec 11, 2008
  27. Jakub NarebskiDec 11, 2008
  28. Jakub NarebskiDec 11, 2008
  29. Jakub NarebskiDec 11, 2008
  30. gitweb: Incremental blame (proof of concept)Jakub Narebski, Dec 14, 2008
  31. [RFC] gitweb: Incremental blame - suggestions for improvementsJakub Narebski, Dec 14, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.