Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame

From: Lea Wiemann <lewiemann@gmail.com>
Date: Jun 3, 2008, 23:11 UTC
Message-ID: <4845CF9F.10604@gmail.com>
In-Reply-To: <200806032224.08714.jnareb@gmail.com>

Jakub Narebski wrote:

Show 5 quoted lines

> I don't think %parent_commits hash is suitable for caching; it is only
> intermediate step, reducing number of git command calls (and forks) [...]
> 
> ATTENTION! This example shows where caching [parsed] data have problems 
> compared to front-end caching (caching output).

ATTENTION! Could we please stop having this discussion?! Your argument is completely bogus. If the parent commit hashes are in cache, it's an almost zero-time cache lookup. The only difference it might make compared front-end caching is the CPU time it takes to generate the page, and *I want to see benchmarks before I even start thinking about CPU*. Okay? Good, thanks.

Sorry I'm a little indignant, but you seem to be somehow trying to tell me what to implement, and that gets annoying after a while. I don't mind your input, but at some point the discussion just doesn't go any further.

> Problems occur when we try to cache page with _streaming_ output, such 
> as blob view, blame view, diff part of commitdiff etc.

We can still stream backend-cache-backed data, though it's a little harder. It's mostly a memory, not a performance issue though -- the only point where I think it actually would be performance-relevant is blame, and blame doesn't stream anyway (see below).

> By the way, if we agree that version %parent_commits is too intrusive 
> dusring GSoC 2008,

Oh, I don't mind, FTR.  It's not enough lines to matter.

Show 5 quoted lines

>> 2) Major point: You're still forking a lot.  The Right Thing is to
>> condense everything into a single call
> 
> This is not a good solution for 'blame' view, which is generated "on the 
> fly", by streaming git-blame output via filter.

No, whether you have your "while <$fd>" loop or not doesn't make a difference. Blame first calculates the whole blame and then dumps it out in zero-time, unless you use --incremental. So there's no performance difference in getting all blame output and then dumping it out vs. reading and outputting it line-by-line. And regarding memory, if your blame output doesn't fit into your RAM, you have different kinds of issues.

JFTR, I don't have any opinion about extending the porcelain output of git-blame (apart from the fact that happens to not be useful for gitweb for the reason I outlined in the previous paragraph).

-- Lea