Re: What's in git.git

Fredrik Kuivinen [off-list ref] writes:

On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:

quoted

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.