[RFC] gitweb: Incremental blame - suggestions for improvements

[Jakub Narebski <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