threads / discuss / 30836

Blaming differences

Subject: Blaming differences

## tl;dr

4 messages between Jun 18, 2012 and Jun 20, 2012.

replies: 3people: 3as markdown or json

Phil Hord· Jun 18, 2012, 22:56 UTC · lore

I want something like a product of diff and blame. I want to see some kind of "blame" output for each line of "diff -U0".

I tried something like this:
   git blame $changed_files
Is there such a command already?
I'd also like to do something of the inverse operation:  I want to
find commits within a range whose changes are NOT in some other
commit.   So, say I have these four commits
   A---B---C---D
Where D was created by 'git revert B'.
I'd like to find out somehow that this is equivalent to
   A--C

So that if I remove B and D completely, the with just A and C will get me to the same end result.

Something like 'git list-contributors HEAD' which would show me A and C, since these are the only commits that appear in any 'git blame $any_file'.

Do these tools exist?  Is it too expensive?
Phil
Thomas Rast· Jun 19, 2012, 07:07 UTC · re: Phil Hord · lore

Re: Blaming differences

Phil Hord <phil.hord@gmail.com> writes:
Show 7 quoted lines
> I want something like a product of diff and blame.  I want to see some
> kind of "blame" output for each line of "diff -U0".
>
> I tried something like this:
>    git blame $changed_files
>
> Is there such a command already?
Perhaps the WIP 'log -L' feature can help:
  http://thread.gmane.org/gmane.comp.version-control.git/199385
Show 15 quoted lines
> I'd also like to do something of the inverse operation:  I want to
> find commits within a range whose changes are NOT in some other
> commit.   So, say I have these four commits
>    A---B---C---D
>
> Where D was created by 'git revert B'.
> I'd like to find out somehow that this is equivalent to
>    A--C
>
> So that if I remove B and D completely, the with just A and C will get
> me to the same end result.
>
> Something like 'git list-contributors HEAD' which would show me A and
> C, since these are the only commits that appear in any 'git blame
> $any_file'.

I wonder if these are really equivalent. The first one is perhaps not feasible: If it can only detect exact reverts, that's not incredibly helpful; the commit message will probably tell you that it's a revert anyway. I suspect that distinguishing conflicted reverts from true changes is AI-complete. You're free to go and try, though :-)

The second one, "find all commits which appear in blame output", is different: it would only list commits which have surviving lines. For example,

  $ git blame --incremental commit.h | grep -E -o '^[0-9a-f]{40}' | sort -u | wc -l
  77
  $ git rev-list --no-merges HEAD -- commit.h | wc -l
  110

tells me that there are 33 commits changing commit.h without any surviving lines. However there were no reverts:

  $ git log --grep=Revert -- commit.h
comes up empty.
-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Chris Packham· Jun 20, 2012, 00:35 UTC · re: Phil Hord · lore

Re: Blaming differences

On Tue, Jun 19, 2012 at 10:56 AM, Phil Hord <phil.hord@gmail.com> wrote:
Show 31 quoted lines
> I want something like a product of diff and blame.  I want to see some
> kind of "blame" output for each line of "diff -U0".
>
> I tried something like this:
>   git blame $changed_files
>
> Is there such a command already?
>
> I'd also like to do something of the inverse operation:  I want to
> find commits within a range whose changes are NOT in some other
> commit.   So, say I have these four commits
>   A---B---C---D
>
> Where D was created by 'git revert B'.
> I'd like to find out somehow that this is equivalent to
>   A--C
>
> So that if I remove B and D completely, the with just A and C will get
> me to the same end result.
>
> Something like 'git list-contributors HEAD' which would show me A and
> C, since these are the only commits that appear in any 'git blame
> $any_file'.
>
> Do these tools exist?  Is it too expensive?
>
> Phil
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I've just run into a situation at $dayjob where something like this would be useful for me so I thought I'd throw my use-case into the mix if anyone decides to pick this idea up.

I'm doing a peer review of a modest project that's been developed off in a branch of it's own before it will be merged back to master. Our current policy is to let these project merges reflect reality warts an all (e.g. leave in commits and their reverts even if the net result is 0 lines changed). I don't want to waist too much time reviewing commit by commit, especially when one commit might heavily refactor code from an earlier one. However looking at the full 'git diff project ^origin/master' is a bit more code that I can keep in my brain at one time. What I'd find useful is the output of 'git diff project ^origin/master' marked up with the sha1s which I could then use as a leaping off point.

Something like this could get me part way there
  for x in $(git diff --name-only project ^origin/master)
  do
    echo git blame project ^origin/master -- $x >$x.ann
  done

But I'd still have to figure out how to reduce the annotated files down to something useful. The git blame -L option might help if I could specify it multiple times and parse the diff output, alternatively since it's not a huge number of revs I multiple invocations of git blame would work for me. I'll have a go at hacking something up after lunch.

Chris Packham· Jun 20, 2012, 02:45 UTC · re: Chris Packham · lore

Re: Blaming differences

On Wed, Jun 20, 2012 at 12:35 PM, Chris Packham <judge.packham@gmail.com> wrote:
Show 62 quoted lines
> On Tue, Jun 19, 2012 at 10:56 AM, Phil Hord <phil.hord@gmail.com> wrote:
>> I want something like a product of diff and blame.  I want to see some
>> kind of "blame" output for each line of "diff -U0".
>>
>> I tried something like this:
>>   git blame $changed_files
>>
>> Is there such a command already?
>>
>> I'd also like to do something of the inverse operation:  I want to
>> find commits within a range whose changes are NOT in some other
>> commit.   So, say I have these four commits
>>   A---B---C---D
>>
>> Where D was created by 'git revert B'.
>> I'd like to find out somehow that this is equivalent to
>>   A--C
>>
>> So that if I remove B and D completely, the with just A and C will get
>> me to the same end result.
>>
>> Something like 'git list-contributors HEAD' which would show me A and
>> C, since these are the only commits that appear in any 'git blame
>> $any_file'.
>>
>> Do these tools exist?  Is it too expensive?
>>
>> Phil
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> I've just run into a situation at $dayjob where something like this
> would be useful for me so I thought I'd throw my use-case into the mix
> if anyone decides to pick this idea up.
>
> I'm doing a peer review of a modest project that's been developed off
> in a branch of it's own before it will be merged back to master. Our
> current policy is to let these project merges reflect reality warts an
> all (e.g. leave in commits and their reverts even if the net result is
> 0 lines changed). I don't want to waist too much time reviewing commit
> by commit, especially when one commit might heavily refactor code from
> an earlier one. However looking at the full 'git diff project
> ^origin/master' is a bit more code that I can keep in my brain at one
> time. What I'd find useful is the output of 'git diff project
> ^origin/master' marked up with the sha1s which I could then use as a
> leaping off point.
>
> Something like this could get me part way there
>
>  for x in $(git diff --name-only project ^origin/master)
>  do
>    echo git blame project ^origin/master -- $x >$x.ann
>  done
>
> But I'd still have to figure out how to reduce the annotated files
> down to something useful. The git blame -L option might help if I
> could specify it multiple times and parse the diff output,
> alternatively since it's not a huge number of revs I multiple
> invocations of git blame would work for me. I'll have a go at hacking
> something up after lunch.

So here's my initial attempt. Definitely a long way to go but I think it illustrates the concept. It actually throws away the diff output and produces blame output for the lines modified as a result it doesn't cover annotating lines that have been removed. Ideally the whole diff would be marked up and we'd see annotations for lines that are added or removed as well as for context lines (if present).

← back to recent threads