I'm thinking of something like this: Say I just discovered a problem in a file.... I want to see who worked on it since some revision that I know is working fine (or even something as generic as HEAD~100..). It could be a number of people with different revisions. I would diff to see what changed.... and blame the added lines (blame reverse to try to get as close as possible with a single command in case I want to see what happened with something that was deleted). If I could get blame information of added/deleted lines in a single run, that would help a lot.
Lo and behold: difflame. On Mon, Jan 30, 2017 at 5:26 PM, Jeff King <p...@peff.net> wrote: > On Mon, Jan 30, 2017 at 01:08:41PM -0800, Junio C Hamano wrote: > >> Jeff King <p...@peff.net> 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
