On Mon, Jan 30, 2017 at 01:08:41PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > On Tue, Jan 17, 2017 at 11:24:02PM -0600, Edmundo Carmona Antoranz wrote: > > > >> For a very long time I had wanted to get the output of diff to include > >> blame information as well (to see when something was added/removed). > > > > This is something I've wanted, too. The trickiest part, though, is > > blaming deletions, because git-blame only tracks the origin of content, > > not the origin of a change. > > Hmph, this is a comment without looking at what difflame does > internally, so you can ignore me if I am misunderstood what problem > you are pointing out, but I am not sure how "tracks the origin of > content" could be a problem. > > If output from "git show" says this: > > --- a/file > +++ b/file > @@ -1,5 +1,6 @@ > a > b > -c > +C > +D > d > e > > in order to annotate lines 'a', 'b', 'd', and 'e' for their origin, > you would run 'blame' on the commit the above output was taken from > (or its parent---they are in the context so either would be OK). > > You know where 'C' and 'D' came from already. It's the commit you > are feeding "git show". I think the point (or at least as I understand it) is that the diff is not "git show" for a particular commit. It could be part of a much larger diff that covers many commits. As a non-hypothetical instance, I have a fork of git.git that has various enhancements. I want to feed those enhancements upstream. I need to know which commits should be cherry-picked to get those various enhancements. Looking at "log origin..fork" tells me too many commits, because it includes ones which aren't useful anymore. Either because they already went upstream, or because they were cherry-picked to the fork and their upstream counterparts merged (or even equivalent commits made upstream that obsoleted the features). Looking at "git diff origin fork" tells me what the actual differences are, but it doesn't show me which commits are responsible for them. I can "git blame" each individual line of the diff (starting with "fork" as the tip), but that doesn't work for lines that no longer exist (i.e., when the interesting change is a deletion). > In order to run blame to find where 'c' came from, you need to start > at the _parent_ of the commit the above output came from, and the > hunk header shows which line range to find the final 'c'. So perhaps that explains my comment more. "blame" is not good for finding which commit took away a line. I've tried using "blame --reverse", but it shows you the parent of the commit you are looking for, which is slightly annoying. :) "git log -S" is probably a better tool for finding that. -Peff