--- On Tue, 6/3/08, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > From: Jakub Narebski <jnareb@xxxxxxxxx> > Subject: Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame > To: "Rafael Garcia-Suarez" <rgarciasuarez@xxxxxxxxx> > Cc: git@xxxxxxxxxxxxxxx, "Luben Tuikov" <ltuikov@xxxxxxxxx>, "Sam Vilain" <sam@xxxxxxxxxx> > Date: Tuesday, June 3, 2008, 7:56 AM > Rafael Garcia-Suarez wrote: > > 2008/6/3 Jakub Narebski <jnareb@xxxxxxxxx>: > >>> 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. > > [...] > >> [...]. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
