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

["Rafael Garcia-Suarez" <rgarciasuarez@gmail.com>]

2008/6/3 Jakub Narebski <jnareb@gmail.com>:
>>> By the way, what is the difference between '<<' links and 'br' link
>>> in the above mentioned annotate/blame interface?
>>
>> "br" navigates to another branch from which this file has been
>> integrated (in p4 speak.)
>
> Does it mark merge commits then? Or perhaps branch points?  What
> does "branch from which this file has been integrated" mean in git
> speak (in the terms of DAG of commits)?
>
>
> If the history of a file looks like this
>
>       ....*---*---A---M---C...
>                      /
>           ....*---B-/
>
> and the line comes from "evil merge" M git-blame would return M as
> blamed commit.  If the line comes from one or the other branch, from
> commit A or B, it makes I think no difference to git-blame; git tries
> to be "branch agnostic" (no special meaning to first parent; well,
> besides rev~n notation and --first-parent walk option).  I guess it
> is not the case in Perforce?

No, in perforce the branch you integrate changes from is always explicit.

> [...]
>>> [...].  Will you want to use git-diff-tree
>>> to mark differences from the version we came from (marked by 'hp',
>>> 'hpb' and 'fp' URI parameters), or would you rather extend git-blame?
>>
>> I don't know. I'll look at git-diff-tree.
>
> What I meant here, would you plan on extending git-blame, or would you
> use patchset (textual) diff between revision we are at, and revision we
> came from.  git-diff-tree just compares two trees (and have to have
> patch output explicitely enabled).  Sorry for the confusion.

I'm under the impression that extending git-blame is a more flexible solution.