Blaming diffs

Blaming diffs

[Mike Hommey]

Hi,

It seems to me there is no tool to "blame diffs", i.e. something to know
what commit(s) is(are) responsible for a set of changes.

For example, the following script tries to get the set of commits
involved in the changes between $A and $B. Note it only works for text
additions. 

git diff --unified=0 $A $B | awk 'BEGIN { FS="(^(--- a/|+++ b/)|^@@ -[0-9,]+ \\+| @@)" } /^---/ || ( /^+++ b\/(.*)/ && file=="" ) { file = $2 } /^@@/ {split($2, a, /,/); a[2] = a[2] ? a[2] + a[1] - 1 : a[1]; print "git blame -l -L " a[1] "," a[2], "'$A..$B'", file }' | sh | cut -f 1 -d " " | sort -u

Has anyone tried to work on something similar yet ?

If not, as git users, what kind of output would you expect from such a
tool, and where do you think this should lie (extension to git diff, or
separate tool) ?

Cheers,

Mike

Re: Blaming diffs

[Frank Lichtenheld]

On Sun, Sep 16, 2007 at 06:38:29PM +0200, Mike Hommey wrote:
> It seems to me there is no tool to "blame diffs", i.e. something to know
> what commit(s) is(are) responsible for a set of changes.
> 
> For example, the following script tries to get the set of commits
> involved in the changes between $A and $B. Note it only works for text
> additions. 
> 
> git diff --unified=0 $A $B | awk 'BEGIN { FS="(^(--- a/|+++ b/)|^@@ -[0-9,]+ \\+| @@)" } /^---/ || ( /^+++ b\/(.*)/ && file=="" ) { file = $2 } /^@@/ {split($2, a, /,/); a[2] = a[2] ? a[2] + a[1] - 1 : a[1]; print "git blame -l -L " a[1] "," a[2], "'$A..$B'", file }' | sh | cut -f 1 -d " " | sort -u
> 
> Has anyone tried to work on something similar yet ?
> 
> If not, as git users, what kind of output would you expect from such a
> tool, and where do you think this should lie (extension to git diff, or
> separate tool) ?

What do you use for $A and $B? commits? What is the difference between
your script and "git log --pretty=format:%H $A..$B"
then?

Gruesse,
-- 
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/

Re: Blaming diffs

[Mike Hommey]

On Sun, Sep 16, 2007 at 07:05:35PM +0200, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Sun, Sep 16, 2007 at 06:38:29PM +0200, Mike Hommey wrote:
> > It seems to me there is no tool to "blame diffs", i.e. something to know
> > what commit(s) is(are) responsible for a set of changes.
> > 
> > For example, the following script tries to get the set of commits
> > involved in the changes between $A and $B. Note it only works for text
> > additions. 
> > 
> > git diff --unified=0 $A $B | awk 'BEGIN { FS="(^(--- a/|+++ b/)|^@@ -[0-9,]+ \\+| @@)" } /^---/ || ( /^+++ b\/(.*)/ && file=="" ) { file = $2 } /^@@/ {split($2, a, /,/); a[2] = a[2] ? a[2] + a[1] - 1 : a[1]; print "git blame -l -L " a[1] "," a[2], "'$A..$B'", file }' | sh | cut -f 1 -d " " | sort -u
> > 
> > Has anyone tried to work on something similar yet ?
> > 
> > If not, as git users, what kind of output would you expect from such a
> > tool, and where do you think this should lie (extension to git diff, or
> > separate tool) ?
> 
> What do you use for $A and $B? commits? What is the difference between
> your script and "git log --pretty=format:%H $A..$B"
> then?

In my typical usecase, $A is upstream and $B is HEAD. What happens is
that my work branch includes some changes that have been merged upstream
and some others that are not yet, or won't because it's not appropriate.
I obviously occasionally merge the upstream branch back, in which case
my changes that were committed upstream don't appear in a git diff $A $B
anymore.

git log --pretty=format:%H $A..$B would give me the list of all commits
that occurred on my branch, while my script only gives the commits
containing changes that are still not applied upstream.

Mike

Re: Blaming diffs

[Shawn O. Pearce]

Christian Couder <chriscool@tuxfamily.org> wrote:
> Le dimanche 16 septembre 2007, Mike Hommey a écrit :
> >
> > It seems to me there is no tool to "blame diffs", i.e. something to know
> > what commit(s) is(are) responsible for a set of changes.
> 
> I don't know if that's what you are looking for but perhaps you could 
> use "git bisect run". You just need to pass it a script that returns 1 when 
> it finds the changes and 0 otherwise. (See git-bisect man page.)

That's very inefficient to search for something...
 
> Sometimes ago I sent a patch that would allow "!" after "git bisect run", 
> but it seems to have been forgotten. This patch makes it possible to use:
> 
> git bisect run ! grep some_stuff file1 file2...
> 
> This would give you the commit where some_stuff was introduced in file1 or 
> file2...

Is `git log -Ssome_stuff -- file1 file2` somehow not working for you?

-- 
Shawn.

Re: Blaming diffs

[Christian Couder]

Le dimanche 16 septembre 2007, Mike Hommey a écrit :
> Hi,
>
> It seems to me there is no tool to "blame diffs", i.e. something to know
> what commit(s) is(are) responsible for a set of changes.

I don't know if that's what you are looking for but perhaps you could 
use "git bisect run". You just need to pass it a script that returns 1 when 
it finds the changes and 0 otherwise. (See git-bisect man page.)

Sometimes ago I sent a patch that would allow "!" after "git bisect run", 
but it seems to have been forgotten. This patch makes it possible to use:

git bisect run ! grep some_stuff file1 file2...

This would give you the commit where some_stuff was introduced in file1 or 
file2...

Regards,
Christian.

Re: Blaming diffs

[Christian Couder]

Le lundi 17 septembre 2007, Shawn O. Pearce a écrit :
> Christian Couder <chriscool@tuxfamily.org> wrote:
> > I don't know if that's what you are looking for but perhaps you could
> > use "git bisect run". You just need to pass it a script that returns 1
> > when it finds the changes and 0 otherwise. (See git-bisect man page.)
>
> That's very inefficient to search for something...

Perhaps but you can search using whatever script or command you want/know. 
You are not limited by those implemented in git.

You can also make it more efficient with "git bisect {start,good,bad}".

Regards,
Christian.

Re: Blaming diffs

[Junio C Hamano]

Christian Couder <chriscool@tuxfamily.org> writes:

> Le lundi 17 septembre 2007, Shawn O. Pearce a écrit :
>> Christian Couder <chriscool@tuxfamily.org> wrote:
>> > I don't know if that's what you are looking for but perhaps you could
>> > use "git bisect run". You just need to pass it a script that returns 1
>> > when it finds the changes and 0 otherwise. (See git-bisect man page.)
>>
>> That's very inefficient to search for something...
>
> Perhaps but you can search using whatever script or command you want/know. 
> You are not limited by those implemented in git.
>
> You can also make it more efficient with "git bisect {start,good,bad}".

I _think_ the inefficiency Shawn refers to is that "git bisect"
wrapper inherently is based on checking out the revision.  It is
similar to "filter-branch --tree-filter" being much more
inefficient than "filter-branch --index-filter" (the latter only
works with index while the former does a full checkout).

The underlying "git rev-list --bisect" can be used to ask for
sequence of commits to check if your check does not require a
full checkout, but there is no wrapper like "git bisect" that 
uses that mode of operation.