2008/6/3 Jakub Narebski <jnareb@xxxxxxxxx>: >>> 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. -- 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
