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

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jun 3, 2008, 21:09 UTC
Message-ID: <655725.88869.qm@web31813.mail.mud.yahoo.com>
In-Reply-To: <200806031656.04780.jnareb@gmail.com>

--- On Tue, 6/3/08, Jakub Narebski <jnareb@gmail.com> wrote:

Show 50 quoted lines

> From: Jakub Narebski <jnareb@gmail.com>
> Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame
> To: "Rafael Garcia-Suarez" <rgarciasuarez@gmail.com>
> Cc: git@vger.kernel.org, "Luben Tuikov" <ltuikov@yahoo.com>, "Sam Vilain" <sam@vilain.net>
> Date: Tuesday, June 3, 2008, 7:56 AM
> 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?

The whole point of git_blame2() was to show which "previous" commit changed that line/segment and what the commit message was. This is important to me when data-mining code evolution, since often enough I'd like to recollect mine/other's intentions at the time of changing/adding the code/commit in question.

Show 18 quoted lines

> 
> [...]
> >> [...].  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'd rather stray away from "git-diff-xyz", since there is no context. Context is found in the commit message which changed the line/segment. (By "context" I mean the human intention, most likely encoded in the commit message.)

Thanks everyone!
   Luben