PSA: git hyper-blame lets you skip unwanted commits

[Matt Giuca]

Hi Chromium / Blink devs,

I wrote a tool called "git hyper-blame" that is basically git blame but you can specify a commit or commits to be ignored.

Say you're trying to figure out who wrote a particular line of code, and git blame tells you it's just a giant commit that renamed or reformatted all the code. Now you can just run git hyper-blame with -i <the-giant-commit>, and it will figure out who really wrote that code.

Blink will soon be doing some serious reformatting and we will set up hyper-blame to automatically ignore these commits. In the mean time, you can try it out on any commit by manually specifying a -i option. It should already be in your depot_tools. I'd love to get your feedback on where it works/doesn't work.

There is no gitiles support yet. That is a pretty big project that will take me some time. Let me know on https://crbug.com/584560 if you want to help out.

Matt

[Tomasz Mikolajewski]

This is super useful! I was thinking about something similar in the past. Does it deal with renamed/moved files?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Matt Giuca]

On Tue, 23 Feb 2016 at 15:49 Tomasz Mikolajewski <mto...@chromium.org> wrote:

This is super useful! I was thinking about something similar in the past. Does it deal with renamed/moved files?

I think it does but I haven't really tested around that (oops). git blame automatically tracks across renames so I didn't have to handle that case specifically. I will experiment and write some more tests around this.

[Gabriel Charette]

This is oh so amazing (If it does what I think it does; i.e. follow the chain across code moves and file renames), thanks!

Can the config of auto-ignored changes be in src/ so that anyone doing such a no-op refactoring can add to it in the same CL?

Can the tool explicitly print the list of ignored changes (in case the user actually cares to know that the code moved) -- maybe it already does haven't tried it yet :-).

Something like:

> git hyper-blame -i <sha2> -L255 -- src/foo.cc

Ignored commits:

 - <sha2> : Sha2 title

 - <sha3> : Sha3 title

Relevant blame:

 - <sha4> : Sha4 title

Cheers!

Gab

[Jeremy Roman]

On Tue, Feb 23, 2016 at 8:00 AM, Gabriel Charette <g...@chromium.org> wrote:

This is oh so amazing (If it does what I think it does; i.e. follow the chain across code moves and file renames), thanks!

Can the config of auto-ignored changes be in src/ so that anyone doing such a no-op refactoring can add to it in the same CL?

Adding to the file changes the SHA-1 of the commit, so you can't do it in the same CL. :)

[Nico Weber]

On Tue, Feb 23, 2016 at 10:21 AM, Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Feb 23, 2016 at 8:00 AM, Gabriel Charette <g...@chromium.org> wrote:

This is oh so amazing (If it does what I think it does; i.e. follow the chain across code moves and file renames), thanks!

Can the config of auto-ignored changes be in src/ so that anyone doing such a no-op refactoring can add to it in the same CL?

Adding to the file changes the SHA-1 of the commit, so you can't do it in the same CL. :)

But other than that, yes, this is possible, see src/.git-blame-ignore-revs if you synced recently. I think this file should be used judiciously though :-)

[Gabriel Charette]

On Tue, Feb 23, 2016 at 10:25 AM Nico Weber <tha...@chromium.org> wrote:

On Tue, Feb 23, 2016 at 10:21 AM, Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Feb 23, 2016 at 8:00 AM, Gabriel Charette <g...@chromium.org> wrote:

This is oh so amazing (If it does what I think it does; i.e. follow the chain across code moves and file renames), thanks!

Can the config of auto-ignored changes be in src/ so that anyone doing such a no-op refactoring can add to it in the same CL?

Adding to the file changes the SHA-1 of the commit, so you can't do it in the same CL. :)

Ah, indeed :-).

 

But other than that, yes, this is possible, see src/.git-blame-ignore-revs if you synced recently. I think this file should be used judiciously though :-)

Right, I think we should be strict about not modifying git blame's output, but perhaps git hyper-blame could be a bit looser (especially if it prints ignored revs).

[Matt Giuca]

On Wed, 24 Feb 2016 at 02:30 Gabriel Charette <g...@chromium.org> wrote:

On Tue, Feb 23, 2016 at 10:25 AM Nico Weber <tha...@chromium.org> wrote:

On Tue, Feb 23, 2016 at 10:21 AM, Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Feb 23, 2016 at 8:00 AM, Gabriel Charette <g...@chromium.org> wrote:

This is oh so amazing (If it does what I think it does; i.e. follow the chain across code moves and file renames), thanks!

Can the config of auto-ignored changes be in src/ so that anyone doing such a no-op refactoring can add to it in the same CL?

Adding to the file changes the SHA-1 of the commit, so you can't do it in the same CL. :)

Ah, indeed :-).

Right. So if you do a refactor CL, you have to then do a follow-up CL to add it to .git-blame-ignore-revs. We thought about this and there isn't much we can do about it. iannucci@ suggested using git-notes so it didn't have to be added as a separate CL, but that creates a lot of additional complexity.

I think this is probably good. It means you need a separate code review to add a new CL to be ignored, which should be treated as a fairly serious operation and not something people do on a day-to-day basis.

 

But other than that, yes, this is possible, see src/.git-blame-ignore-revs if you synced recently. I think this file should be used judiciously though :-)

Right, I think we should be strict about not modifying git blame's output, but perhaps git hyper-blame could be a bit looser (especially if it prints ignored revs).

In response to your earlier request (printing ignored revs), it just puts an asterisk next to any line that has been skipped over, so you know an ignored CL was blamed. I don't want to spam the output with more details; you can use normal git blame if you want to investigate what actually changed that line. (See man page for an example.)

I think we should also be strict with hyper-blame, because it may end up that hyper-blame is your main blame tool (esp. on Blink where the whole source tree will be reformatted), and people will rely on it to not skip over any random commits that people didn't want you to see.

[Matt Giuca]

On Wed, 24 Feb 2016 at 12:36 Yoichi Osato <yoi...@chromium.org> wrote:

+1.

Plus, I want something like that on https://chromium.googlesource.com.

That is gitiles (see my original email: "There is no gitiles support yet. That is a pretty big project that will take me some time. Let me know on https://crbug.com/584560 if you want to help out.").

 

That's because I sometime need to find the 'right' CL of code.

I need dive into a blame chain like peeling onion. 

A link [parent of this blame] fixes that?

Yeah, a simple link to the parent of the blame would fix that. I've seen complaints about this before. Adding that to gitiles would be much easier than porting hyper-blame to gitiles.

 

2016年2月24日(水) 8:31 Matt Giuca <mgi...@chromium.org>:

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Scott Graham]

I did what I think you're asking for here: https://gerrit-review.googlesource.com/#/c/74630/ but it didn't get much traction.

On Tue, Feb 23, 2016 at 5:36 PM, Yoichi Osato <yoi...@chromium.org> wrote:

+1.

Plus, I want something like that on https://chromium.googlesource.com.

That's because I sometime need to find the 'right' CL of code.

I need dive into a blame chain like peeling onion. 

A link [parent of this blame] fixes that?

2016年2月24日(水) 8:31 Matt Giuca <mgi...@chromium.org>:

On Wed, 24 Feb 2016 at 02:30 Gabriel Charette <g...@chromium.org> wrote:

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.