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

[Jakub Narebski <jnareb@gmail.com>]

Rafael Garcia-Suarez wrote:
> 2008/6/3 Jakub Narebski <jnareb@gmail.com>:
>>> Shameless plug : the sources for perl 5 are currently being kept in a
>>> perforce repository. There is a rough web interface to it at
>>> http://public.activestate.com/cgi-bin/perlbrowse with excellent blame
>>> log navigation features (including navigation against p4
>>> integrations).
>>
>> 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?

[...]
>> [...].  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.

-- 
Jakub Narebski
Poland