From: Junio C Hamano Date: Wed, 04 Jun 2008 05:58:07 GMT Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame Message-ID: <7v3ant213k.fsf@gitster.siamese.dyndns.org> In-Reply-To: <200806032331.44514.jnareb@gmail.com> Jakub Narebski 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.