Support ignoring commits in blame (blame.ignoreRevsFile config option)
Problem to solve
I want to ignore commits when viewing blame (available as of git 2.23)
Intended users
Everyone except Buyers (and Product Managers?).
Further details
Use cases:
- Add a formatting tool to the project without breaking git blame.
- Perform minor refactorings (e.g. rename a variable) without affecting the blame.
Proposal
Add a new file in repository to specify the file1 normally specified blame.ignoreRevsFile, and UI toggles for config options blame.markUnblamables and blame.markIgnoredLines.
The blame view then incorporates the algorithm implemented in git to re-assign blame to each line.
UI options should include override toggles for the above specified blame.mark* flags, and there should be a UI hint that lets users know revisions are being ignored.
Note If git is ever updated to include a default place to look for these settings that lives inside the repo, this feature should automatically activate, with an option to opt-out.
Handling ignoring of specific files
From gitaly!4177 (closed):
This MR implements keeps a copy of
.git-blame-ignore-revsinside of the repository atinfo/blame-ignore-revs, similar to how.gitattributesandinfo/attributeswork.RawBlame()then checks for the existence of this file and loads it into the git blame command using--ignore-revs-fileif it exists.
In the blame view, there will be a new dropdown button Blame preferences.
| Default Idle | Prompt for setup | Ignore file in place and toggled on |
|---|---|---|
 |
 |
 |
When the blame view has the toggle on for Ignore specific revisions, there will be a UI hint in the form of text saying [View file] to see list of ignored revisions.. Clicking on "View file" would take the user to the .git-blame-ignore-revs file.
Marking unblamables and ignored lines
In the dropdown we can extend the functionality to toggle the ability to Mark unblamables and Mark ignored lines.
| Ignore Specific Revisions | Extended to toggle Ignore and Mark settings |
|---|---|
 |
 |
Permissions and Security
Only project owners/maintainers can specify these options at a project level. (Not 100% sure on this one...)
Documentation
Testing
- The blame output of the git client should match gitlab's blame, given the same configuration.
(not sure how this would be implemented)
- Risk: May need to reimplement git functionality. Updates to the reblaming algorithm would need to be tracked in this case.
What does success look like, and how can we measure that?
Users can see the same blame in the gitlab UI and the git client. More people would start converting projects to use auto-formatters.