# Blaming diffs 7 messages from 2007-09-16 to 2007-09-17. Participants: Mike Hommey, Frank Lichtenheld, Christian Couder, Shawn O. Pearce, Junio C Hamano. Thread: https://gitlist.dev/t/9878 ## Mike Hommey, 2007-09-16 16:38 Subject: Blaming diffs Message-ID: <20070916163829.GA6679@glandium.org> URL: https://gitlist.dev/e/20070916163829.GA6679%40glandium.org ``` 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 ``` ## Frank Lichtenheld, 2007-09-16 17:05 Subject: Re: Blaming diffs Message-ID: <20070916170534.GU22865@planck.djpig.de> URL: https://gitlist.dev/e/20070916170534.GU22865%40planck.djpig.de In-Reply-To: <20070916163829.GA6679@glandium.org> ``` 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 www: http://www.djpig.de/ ``` ## Mike Hommey, 2007-09-16 17:16 Subject: Re: Blaming diffs Message-ID: <20070916171635.GA8868@glandium.org> URL: https://gitlist.dev/e/20070916171635.GA8868%40glandium.org In-Reply-To: <20070916170534.GU22865@planck.djpig.de> ``` On Sun, Sep 16, 2007 at 07:05:35PM +0200, Frank Lichtenheld 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 ``` ## Shawn O. Pearce, 2007-09-17 04:57 Subject: Re: Blaming diffs Message-ID: <20070917045704.GH3099@spearce.org> URL: https://gitlist.dev/e/20070917045704.GH3099%40spearce.org In-Reply-To: <200709170659.15655.chriscool@tuxfamily.org> ``` Christian Couder 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. ``` ## Christian Couder, 2007-09-17 04:59 Subject: Re: Blaming diffs Message-ID: <200709170659.15655.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/200709170659.15655.chriscool%40tuxfamily.org In-Reply-To: <20070916163829.GA6679@glandium.org> ``` 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. ``` ## Christian Couder, 2007-09-17 05:40 Subject: Re: Blaming diffs Message-ID: <200709170740.00917.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/200709170740.00917.chriscool%40tuxfamily.org In-Reply-To: <20070917045704.GH3099@spearce.org> ``` Le lundi 17 septembre 2007, Shawn O. Pearce a écrit : > Christian Couder 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. ``` ## Junio C Hamano, 2007-09-17 05:41 Subject: Re: Blaming diffs Message-ID: <7vy7f53l3f.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vy7f53l3f.fsf%40gitster.siamese.dyndns.org In-Reply-To: <200709170740.00917.chriscool@tuxfamily.org> ``` Christian Couder writes: > Le lundi 17 septembre 2007, Shawn O. Pearce a écrit : >> Christian Couder 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. ```