Blaming differences

Blaming differences

[Phil Hord]

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

Re: Blaming differences

[Thomas Rast]

Phil Hord <phil.hord@gmail.com> writes:

> 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

> 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

Re: Blaming differences

[Chris Packham]

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.

Re: Blaming differences

[Chris Packham]

[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]

On Wed, Jun 20, 2012 at 12:35 PM, Chris Packham <judge.packham@gmail.com> wrote:
> 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).

[-- Attachment #2: git-annotate-diff.sh --]
[-- Type: application/x-sh, Size: 629 bytes --]