Maybe a little work on blame to get the actual revision where some lines were "deleted"? Something like git blame --blame-deletion that could be based on --reverse? On Mon, Jan 30, 2017 at 7:35 PM, Edmundo Carmona Antoranz <eantoranz@xxxxxxxxx> wrote: > 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 <peff@xxxxxxxx> wrote: >> 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