Support --ignore-revs-file for blame view to support automated code formatters

[jezdez]

When using automated code formatters to format a legacy project (read: code not matching an automated code formatter's style) it would be splendid to be able to make sure the commits related to the reformatting wouldn't be taken into account in GitHub's blame page.

Here's some background in the docs for Python's popular "black" code formatter: https://black.readthedocs.io/en/stable/guides/introducing_black_to_your_project.html#avoiding-ruining-git-blame

A long-standing argument against moving to automated code formatters like Black is that the migration will clutter up the output of git blame. This was a valid argument, but since Git version 2.23, Git natively supports ignoring revisions in blame with the --ignore-rev option. You can also pass a file listing the revisions to ignore using the --ignore-revs-file option. The changes made by the revision will be ignored when assigning blame. Lines modified by an ignored revision will be blamed on the previous revision that modified those lines.

In case anyone wants to spread the call for this feature in their network, feel free to retweet https://twitter.com/jezdez/status/1425467443242221571 🥳

NOTE: Please use the arrow in the top left corner (on Desktop) or below the text (on mobile) to upvote this, in addition to the 👍🏻!

[sfdye]

Linking the 1-year-old github community post here
https://github.community/t/support-ignore-revs-file-in-githubs-blame-view/3256/27

There are 150+ votes from there

[Pike]

Not only does this matter when updating legacy code bases, but also when updating versions of those formatters. I don't recall if there was a reason, but .git-blame-ignore-revs might be a common file name to commit to publish changesets to ignore.

[yashkumarverma-fampay]

This is a really demanded and useful feature, especially for projects that are formatted after long durations - or formatters being changed. expecting a timely resolution of this :)
@YashKumarVerma

[davidstaheli]

Thank you for suggesting this! It would be such a valuable feature. It's currently on our backlog and we will give it high priority. I can't yet provide a definite date because we're still sizing it and determining how the blame UI should adapt.

Current thinking is that if a .git-blame-ignore-revs file is in the root of the repository, the blame UI will ignore the revisions in the file. Though we might start with only that, does anyone need more than that? For example:

• Do you need support for more than one file of revisions to ignore? The Git CLI allows more than one file to be specified, either by repeating the blame.ignoreRevsFile config option or by repeating the --ignore-revs-file <file> command line option.
• Do you need to manually specify other revisions to ignore at the time that you're actually viewing blame information? The Git CLI, in addition to letting you configure a file of revs to ignore, allows specifying individual revs to ignore on-the-fly with the --ignore-rev <rev> option.

Please reply if you will need one of the options above or have other suggestions. Thanks!

[nchudleigh]

Do you need support for more than one file of revisions to ignore?
For our company which has around ~15 repos (4-5 are most active), use of prettier & black formatters consistent across JS and Python codebases, no. I don't think that multiple files would be necessary to accomplish our goals of making git blame less noisy from these sweeping formatting changes.

Do you need to manually specify other revisions to ignore at the time that you're actually viewing blame information?
Personally I have not needed this feature or reached for it before.

Current thinking is that if a .git-blame-ignore-revs file is in the root of the repository, the blame UI will ignore the revisions in the file.
I think the automatic usage of this by GitHub would be enough for us given my current knowledge & experiences.

[leonardehrenfried]

For my use case the most basic implementation with a single, non-configurable file would be enough.

[sfdye]

@davidstaheli Thank you for acknowledging this.

Current thinking is that if a .git-blame-ignore-revs file is in the root of the repository, the blame UI will ignore the revisions in the file.

TBH that would be a great start.

Technically you can merge multi ignores flies into one, so I don't think supporting multiple ignore files should block the initial feature rollout.

I am super excited now 😄

[gziolo]

Current thinking is that if a .git-blame-ignore-revs file is in the root of the repository, the blame UI will ignore the revisions in the file. Though we might start with only that, does anyone need more than that?

That would be enough for the WordPress project to list commits with automated code formatting applied at a large scale. We want to include the file in WordPress/gutenberg#37822 with the same name to improve the experience when executing git blame locally. However, it would be phenomenal if it would work out of the box on GitHub seamlessly 😄

[dreamyguy]

Trying to understand this... Wouldn't it require the committer to have the discipline to use dedicated commits for changes triggered by automated code formatters?

Say in case there are actual changes to the code mixed with reformatting triggered by an automated code formatter.

I'm just thinking aloud. Not implying anything, being rhetorical nor sarcastic.

[glopesdev]

I have a related dangling question that I never could find a good answer for. If git blame can ignore specific changes based on a config file, why can it not be configured to ignore all changes that are just line ending changes?

Visual Studio Code for example seems to ignore line endings by default in staging file diffs, although in the past this has made me commit unwanted line ending changes. Maybe this was a big a problem previously but it seems less so now if .gitattributes are configured correctly.

[emilong]

@dreamyguy For my case, we use auto-formatting in a couple of languages and individual commits often do shuffle things around, but those aren't that problematic from a git blame perspective because they're co-located with actual semantic changes. This feature is intended for large, repo-wide reformatting where modifications to files without behavioral changes break the blame chain.

Your question is great one, but it's related to the underlying git feature rather than what this issue is asking of github itself, which is simply instead to expose this existing git feature through the UI.

[davidstaheli]

Update: implementation of this feature is in progress

[dipree]

Update:

Ignoring commits in the blame view is available as a public beta to anyone now 🎉 For more information see the documentation.

---

Hey everyone 👋 we have an early version available in a private beta and would love to get a few more thoughts. If anyone is interested in trying it out early, please let me know with a comment below and we'll enable it for you or your organization account.

Once enabled, you must add a file called .git-blame-ignore-revs to the root level of your repository. That file must contain the revisions (commit hashes) you want to ignore. The blame view of the repository will then be loaded with the --ignore-revs-file parameter and ignores the specified revisions.

[ocean90]

Would like to test this with @GlotPress on https://github.com/GlotPress/GlotPress-WP. Thanks!

[elliottprogrammer]

Awesome for implementing this! Thank you! We also would love to try it out on the @wpscanteam organization.

[dipree]

We have been working to get this shipped and it's available to anyone now!

[hovissimo]

We would be pleased to help test this! https://github.com/hiringthing/HiringThing

[davidstaheli]

This feature is already enabled for everyone now, so it doesn't need to be specially enabled for anyone. https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

[felixxm]

@dipree @davidstaheli Can we also ignore this commits in "Reviewers suggestions"? 🤔 For example, @django-bot is suggested in Django in almost all PRs:

because we used it for Black reformatting.

[dipree]

This has been addressed and @django-bot shouldn't be suggested any longer. Thank you for reporting!

[felixxm]

Many thanks 🥇

[Jackenmen]

First tests seemed to indicate that the revisions in .git-blame-ignore-revs are only ignored if the git blame is done from a branch, not a specific commit. Here are two examples from the https://github.com/Cog-Creators/Red-Lavalink repository:

1. lavalink/utils.py on line 2:

• https://github.com/Cog-Creators/Red-Lavalink/blame/develop/lavalink/utils.py
• https://github.com/Cog-Creators/Red-Lavalink/blame/82c9389031802d2b88f54332135bc6d49778a2a6/lavalink/utils.py

2. LICENSE on lines 676-678:

• https://github.com/Cog-Creators/Red-Lavalink/blame/develop/LICENSE
• https://github.com/Cog-Creators/Red-Lavalink/blame/82c9389031802d2b88f54332135bc6d49778a2a6/LICENSE

However, after testing this with a file from a specific commit that was PRed (Cog-Creators/Red-Lavalink#99), which is what you get when clicking "View file" on the file list, it turns out that sometimes it does show even when doing blame from a specific commit (L64-65):
https://github.com/Cog-Creators/Red-Lavalink/blame/97b369240562a786a44992b56294d8b3fa0d92e8/lavalink/node.py

So I'm not sure what's the rule is here.

[jsoref]

It's a matter of perspective
https://github.com/Cog-Creators/Red-Lavalink/blame/82c9389031802d2b88f54332135bc6d49778a2a6/lavalink/utils.py

Cog-Creators/Red-Lavalink@82c9389

vs:
https://github.com/Cog-Creators/Red-Lavalink/blame/746a24fece08cb9e80092f3db01088eca01d4f3a/lavalink/utils.py

Cog-Creators/Red-Lavalink@746a24f

[6789543]

27 Oca 2022 Per 14:24 tarihinde Wallace Sidhrée ***@***.***> şunu yazdı:

…

Trying to understand this... Wouldn't it require the committer to have the discipline to use dedicated commits for changes triggered by automated code formatters? I'm just thinking aloud. Not implying anything, being rhetorical nor sarcastic. — Reply to this email directly, view it on GitHub <#5033 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXMXN5L3AGCUFSSJOKF47CTUYETQTANCNFSM5B6VRYQQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Jackenmen]

So after thinking about it for a bit, I'm wondering... Could it be made possible to disable this feature when, for some reason, you would want to include changes from ignored revisions in the blame? The default should most definitely be to hide revisions specified in .git-blame-ignore-revs but I feel like not having a way to disable it will bite someone in the future...

[matthew16550]

It's great that this is being worked on 👍.

I agree with @jack1142, sometimes we will want to switch it off.

Suspect my workflow would be:

1. I'm confused by the blame view for a few lines in some file
2. Switch off .git-blame-ignore-revs
3. 1 minute later, I'm a lot less confused
4. Switch it back on again

Perhaps there could be a toggle similar to Hide whitespace in diff views which "just" adds a w=1 query param to the URL and I vaguely remember for a while there was no UI tickbox, we just edited the URL manually. A similar approach might suit here.

[miketheman]

Did this literally just launch to non-private beta? I saw an inconsistency with the "Learn more" url form the notification - could have been cached?
https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view now shows the thing I couldn't see before.

[miketheman]

Answered via #5033 (reply in thread)

[sfc-gh-mheimel]

@dipree This seems to have broken the blame view for one of our files in an internal repo (fully empty blame view). Is there a bug tracker / known list of issues with the feature?

[dipree]

@sfc-gh-mheimel we investigated but couldn't find any problems. However, there has been a little hiccup in the system in the last hour which caused a few 500. Can you please confirm whether it's still broken or works as expected?

[sfc-gh-mheimel]

@dipree Yeah, the blame view for that particular file is still broken as-of right now.

[sfc-gh-mheimel]

It works now :) So, probably just related to the outage after all.

[jpobst]

@dipree Love it! It would be great if this file could also be loaded from .github/ so it doesn't have to clutter the root directory.

[jpobst]

It would be nice to support both, so projects that do not use any other tooling can tuck it away. 😁

I feel like the more files that are in the root directory, the more intimidating a repo is for a new user.

[Jackenmen]

It would be nice to support both, so projects that do not use any other tooling can tuck it away. 😁

You can't know what kinds of tools your contributors are using though? I'm thinking of a simple git blame without having to set a different local git config or different sorts of Git GUI tools who would use this option as default (which means that blaming on a file would be more approachable for repositories that use that location for the ignore revs file) or potentially not even allowing to use different file (though one can hope that if a tool supports it, it wouldn't do that).

[JasonEtco]

👋 We decided to limit it to a root-level file, for the reasons y'all have shared here - its a common convention, that other tools and many projects have already adopted. One reason for not supporting both is that some projects would encounter the reverse, where GitHub uses .github/* but then other tools expect the root-level file, so they'd end up with the root-level file anyway.

We're monitoring this feedback specifically (should the file live in .github) to see if we should adjust in the future, so thank you for sharing!

[janeklb]

Another good reason for not having it in the .github directory is that it's not a core github feature, but a core git feature, and github have (awesomely) extended their blame view to integrate with it.

[sfc-gh-mheimel]

+1 to having it in the root folder. That way it works natively with git tooling in local checkouts of the repository.

[ari-walter]

@dipree I tried it on our repo and it only works partially. The ignored commits still showed up but affected to less lines. Any advice?

[helen]

@ari-walter Do those lines have other commits that should be showing? I noticed this in wordpress/wordpress-develop but when I looked into it further it's because those lines have only been touched by those otherwise-ignored commits (e.g. a coding standards commit that added braces).

[ari-walter]

@helen The commit introduced file scoped name spaces. I was hoping to ignore it but it still shows up on multiple lines throughout the file.

[JonnoFTW]

Does this work with the new pull request interface? I have a repo where:

1. Line endings where changed in a few files (along with a few other things).
2. This change was then reverted and remade without the line ending changes.
3. The first commit hash was added to .git-blame-ignore-revs

The PR viewer still shows the line ending changes despite the original commit being in .git-blame-ignore-revs (all part of the same PR).

[PathogenDavid]

This feature affects blame views, not diff views.

Even if it did, I personally would not want to see it affecting PRs. Seems like a good way for someone to try and sneak in changes without reviewers noticing.

[RaisinTen]

Is there a way to opt out of ignoring the commits from the GitHub blame UI using a button or something? Folks might still be interested in taking a look at the ignored changes even if the .git-blame-ignore-revs file is committed to the repo.
This is in response to the concerns expressed in nodejs/node#43017 that adds the .git-blame-ignore-revs file to Node.js.

[JasonEtco]

Hello @RaisinTen! I worked on this feature, and I've been following the conversation so as not to get in the way, so I could learn from what y'all talked through. There are really two questions here:

Can you turn it off or toggle it

We talked about making this toggle-able as you were looking at a blame, and the more we hear that it'd be a useful improvement to this feature, the more we'll know that it's worth doing. So, thank you for sharing that request!

Contributing to the file can be a thing™️

Re: the conversation in nodejs/node#43017 (I'm happy to chime in there if you'd like), I totally understand the concern with slowing contribution time. Unfortunately, this isn't a GitHub feature per se - the chicken-and-egg situation where you want to ignore a commit before you've committed it is true for the git blame command line flag as well.

If a project has too complex a workflow to use this feature, I think (as someone who worked on making it happen) that it is perfectly okay not to use it. This feature is best suited for large projects that have these wide-sweeping commits, so it'd be great if its useful in Node, but it sounds like the flow for keeping it up to date is too cumbersome.

[jsoref]

Fwiw, I tend to make sweeping spelling fixes across repositories.

People have asked me about including a record for ignore revs. If they use rebase or squash to merge, then I can't. I'd love for github to be able to recognize that a rebased commit or a squashed commit is referencing a thing and create a follow-on commit that adds the correct commit on the next line of the file.

I'm not opposed to adding the thing, but, it's definitely painful for me as a drive-by contributor.

I think that having the feature in theory should make projects more willing to accept changes like mine since blame to me disappears (and mostly credit to me does as well). And this is fine. I want the spelling errors to you away.

[RaisinTen]

Hey @JasonEtco, thanks for summing up my concerns!

I was also wondering what the recommended way is for using this feature in release branches? I was assuming that changes to this file shouldn't be backported because the commit SHAs will be different from the ones tracked in this file.

[jsoref]

You effectively need to copy the equivalent commit when you backport the referenced commit.

[JasonEtco]

I was also wondering what the recommended way is for using this feature in release branches? I was assuming that changes to this file shouldn't be backported because the commit SHAs will be different from the ones tracked in this file.

Good question - I imagine (and feel free to correct me) that the majority of blaming is done on the main/development branch, not a specific release? If that is the case, then frankly I wouldn't worry about it. Commits on the main branch will be "right." Otherwise, you would just have to manually list the "same commit" by different SHAs, and/or backport that file change in the release branches, and that sounds super painful and not worth the effort IMO.

[paulz]

as coding standard change we use linters and formatter, which breaks GitHub blame

[zwimer]

Are there any plans to support git blame's related config options such as git config blame.markUnblamableLines true ?

[FelixGV]

It would be great if the GitHub Insights tab took the .git-blame-ignore-revs file into account. Or alternatively, it would be great if the GitHub Insights tab stopped counting file moves as a full rewrite of the file... Git itself does not count it this way, but for some reason GitHub does. This means trivial refactoring to the project's directory structure result in outsized impact on the GitHub Insights data.