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

From: Junio C Hamano <[email-masked]>
Date: Tue, 03 Jun 2008 22:58:07 -0700

Jakub Narebski <[email-masked]> writes:

>> The intention was that it shouldn't necessarily be the (strict) parent
>> of the change (changed segment), since it may or may not have changed
>> in the strict parent commit.  The intention was that it
>> "starts"/"opens" the parent commit so that "git" would start from
>> there and find the actual change/commit where that line/segment has
>> changed.  And it has worked pretty fine for me when data-mining
>> (something I do quite often) code evolution.

Yes, but the current scheme breaks down in another way.  When $full_rev
added many lines to the file, and you are adding the link to for a line
near the end of the file and such a line may not exist.  This cannot be
cheaply done even inside blame itself.

Another breakage is even though $full_rev^ _may_ exist (iow, $full_rev
might not be the root commit), the file being blamed may not exist there
(iow $full_rev might have introduced the file).  Instead of running
"rev-parse $full_rev^", you would at least need to ask "rev-list -1
$full_rev^ -- $path" or something from the Porcelain layer, but
unfortunately this is rather expensive.

Because blame already almost knows if the commit the final blame lies on
has a parent, it would be reasonably cheap to add that "parent or nothing"
information to its --porcelain (and its --incremental) format if we wanted
to.