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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
