Re: What's cooking in git.git (Nov 2009, #05; Sun, 22)
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Nov 24, 2009, 10:53 UTC
- Message-ID
- <m3ljhwb3d6.fsf@localhost.localdomain>
- In-Reply-To
- <7vhbsl935q.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 10 quoted lines
> * jn/gitweb-blame (2009-11-19) 6 commits. > - gitweb.js: fix null object exception in initials calculation > - gitweb: Minify gitweb.js if JSMIN is defined > - gitweb: Create links leading to 'blame_incremental' using JavaScript > (merged to 'next' on 2009-10-11 at 73c4a83) > + gitweb: Colorize 'blame_incremental' view during processing > + gitweb: Incremental blame (using JavaScript) > + gitweb: Add optional "time to generate page" info in footer > > Ajax-y blame, with a few recent fixes.
Unfortunately current version does not work with IE8 (reported by Stephen Boyd); it stops at the very beginning of JavaScript blaming with the two JavaScript errors:
- "firstChild is null or not an object", caused by the fact that '<a href=""> </a>' element doesn't have firstChild which is text node with space as contents in DOM. This can be easily worked around.
- "Unspecified error" (twice (sic!) for the same line), which I have currently no idea how to fix; it points to the following line:
if (xhr.readyState === 3 && xhr.status !== 200) {Show 7 quoted lines
> * pb/gitweb-no-project-list (2009-11-06) 3 commits. > . gitweb: Polish the content tags support > . gitweb: Support for no project list on gitweb front page > . gitweb: Refactor project list routines > > I picked these up but didn't queue as Warthog9's comments made certain > amount of sense to me.
I'd like to see at least refactoring project list subroutine: currently printing list of projects is entangled with filtering said list; IMHO filtering list of projects should be done upfront.
-- Jakub Narebski Poland ShadeHawk on #git