Re: What's in git.git

From: Junio C Hamano <junkio@cox.net>
Date: Mar 13, 2006, 05:01 UTC
Message-ID: <7vlkvfszu5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060310104443.GA4491@c165.ib.student.liu.se>

Fredrik Kuivinen <freku045@student.liu.se> writes:

Show 8 quoted lines

> On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:
>> 
>> Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
>> output like annotate does with -S?
>
> Currently it cannot do that. How is that option used? If you want to
> make annotate/blame faster for certain files you might as well cache
> the output of annotate/blame instead of the git-rev-list output, no?

There are two reasons Martin's git-cvsserver uses -S to feed you the revision list. One is that he already has that ancestry chain information, and there is no point for him to have the git-annotate command to recompute it.

But there is another, more important reason. He is giving his clients a modified world view where the branch he is exposing to have _no_ merges -- just a single strand of pearls. So what is fed to git-annotate using -S from git-cvsserver has either one object name (single root commit) or two (the commit and its sole parent). IOW, he does not want you to look at other parents when dealing with a merge commit.

What this means is that in cases where your algorithm looked at second and subsequent parents to pass remaining blame on after looking at the first parent for a merge, the algorithm now needs to assign the blame to the merge commit itself. Your process_commit() currently reads the commit object and loops over its true parents, but the -S flag wants to supply its own notion of who are the parents of whom (and in the case of git-cvsserver, it always supplies at most one parent) so you would need to honor that instead of looking at the real ancestry.