[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