threads / discuss / 14093

git blame for a commit

Subject: git blame for a commit

## tl;dr

6 messages between Jun 22, 2008 and Jun 23, 2008.

replies: 5people: 3as markdown or json

Mircea Bardac· Jun 22, 2008, 22:32 UTC · lore

Hi everyone,

Is there any straightforward way of doing git blame for all the files that got changed in a commit. Problems are renames, deletes and copies.

I was also thinking of git diff with a huge number of context lines, but this one feels a bit hacking. "git diff" is also missing author info, so "git blame" is a bit more desirable.

Has anyone ever done this before?

Many thanks.

-- 
Mircea
http://mircea.bardac.net

Ian Hilt· Jun 23, 2008, 03:40 UTC · re: Mircea Bardac · lore

Re: git blame for a commit

On Sun, 22 Jun 2008 at 11:32pm +0100, Mircea Bardac wrote:

> Hi everyone,
> 
> Is there any straightforward way of doing git blame for all the files that got
> changed in a commit. Problems are renames, deletes and copies.

Sounds like you want to track files rather than content. Git tracks the latter.

Show 7 quoted lines

> I was also thinking of git diff with a huge number of context lines, but this
> one feels a bit hacking. "git diff" is also missing author info, so "git
> blame" is a bit more desirable.
> 
> Has anyone ever done this before?
> 
> Many thanks.

Try "git diff --name-only commit1..commit2" or "git log --name-only commit1..commit2". This will give you only the names of the files in which content was altered. Other than that, I think you should re-read (hint) git-blame(1). It's focus is on content, not files as a whole.

-- Ian Hilt Ian.Hilt (at) gmx.com GnuPG key: 0x4AFC1EE3

Mircea Bardac· Jun 23, 2008, 09:04 UTC · re: Ian Hilt · lore

Re: git blame for a commit

Ian Hilt wrote:

Show 6 quoted lines

> On Sun, 22 Jun 2008 at 11:32pm +0100, Mircea Bardac wrote:
>> Is there any straightforward way of doing git blame for all the files that got
>> changed in a commit. Problems are renames, deletes and copies.
> 
> Sounds like you want to track files rather than content.  Git tracks the
> latter.

Hmm... I'm not really sure that my initial intention was to track files. I've given this some more thought and I realized that what I actually want is a "git diff" with blame info included. I want this information in order to facilitate code reviewing.

It is true that this would be a front-end functionality, but I am not sure at the moment what the best approach would be for something like this. I would see this something like $ git diff --blame[="parameters_for_blame"] commit1..commit2 but this is just a thought.

Has anyone tried blaming a "git diff"?

Many thanks.

-- Mircea http://mircea.bardac.net

Jakub Narebski· Jun 23, 2008, 10:01 UTC · re: Mircea Bardac · lore

Re: git blame for a commit

Mircea Bardac <dev@mircea.bardac.net> writes:

Show 23 quoted lines

> Ian Hilt wrote:
>> On Sun, 22 Jun 2008 at 11:32pm +0100, Mircea Bardac wrote:
>>>
>>> Is there any straightforward way of doing git blame for all the
>>> files that got changed in a commit. Problems are renames, deletes
>>> and copies.
>>
>> Sounds like you want to track files rather than content.  Git tracks
>> the
>> latter.
> 
> Hmm... I'm not really sure that my initial intention was to track
> files. I've given this some more thought and I realized that what I
> actually want is a "git diff" with blame info included. I want this
> information in order to facilitate code reviewing.
> 
> It is true that this would be a front-end functionality, but I am not
> sure at the moment what the best approach would be for something like
> this. I would see this something like
> $ git diff --blame[="parameters_for_blame"] commit1..commit2
> but this is just a thought.
> 
> Has anyone tried blaming a "git diff"?

I think you could script it using "git diff", and "git blame -L m,n", where line ranges would be calculated from git diff header for post-image, or both pre-image and post-image (in the case of deletions).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Ian Hilt· Jun 23, 2008, 15:55 UTC · re: Jakub Narebski · lore

Re: git blame for a commit

On Mon, 23 Jun 2008 at 3:01am -0700, Jakub Narebski wrote:

> I think you could script it using "git diff", and "git blame -L m,n",
> where line ranges would be calculated from git diff header for
> post-image, or both pre-image and post-image (in the case of deletions).

Maybe I'm missing something, but I thought git-blame only worked with the files in the Git working directory. Therefore, if a file had been deleted it would not be reachable with git-blame, whether you diff'ed the pre- and post-image or not.

-- Ian Hilt Ian.Hilt (at) gmx.com GnuPG key: 0x4AFC1EE3

Jakub Narebski· Jun 23, 2008, 16:29 UTC · re: Ian Hilt · lore

Re: git blame for a commit

On Mon, 23 Jun 2008, Ian Hilt wrote:

Show 10 quoted lines

> On Mon, 23 Jun 2008 at 3:01am -0700, Jakub Narebski wrote:
> 
> > I think you could script it using "git diff", and "git blame -L m,n",
> > where line ranges would be calculated from git diff header for
> > post-image, or both pre-image and post-image (in the case of deletions).
> 
> Maybe I'm missing something, but I thought git-blame only worked with
> the files in the Git working directory.  Therefore, if a file had been
> deleted it would not be reachable with git-blame, whether you diff'ed
> the pre- and post-image or not.

You can give blame the revision to start blaming from; that's what I meant the "pre-image" blame (staring from parent revision).

I'm not that sure if it is the best solution...

-- 
Jakub Narebski
Poland