Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect .git-blame-ignore-revs for reviewer suggestions #191

Open
liamfd-titan opened this issue May 25, 2023 · 1 comment
Open

Respect .git-blame-ignore-revs for reviewer suggestions #191

liamfd-titan opened this issue May 25, 2023 · 1 comment
Labels
enhancement New feature or request roadmap

Comments

@liamfd-titan
Copy link

liamfd-titan commented May 25, 2023

Is your feature request related to a problem? Please describe.
We have a .git-blame-ignore-revs file that we use to strip out commits that cause noise in the blame. Here's a blog post (chosen randomly, there are a bunch) describing this in more detail: https://michaelheap.com/git-ignore-rev/

While the underlying git setting doesn't care what the filepath is, just a .git-blame-ignore-revs in the root of the repo appears to be the de facto standard. For example, github's web blame diff view automatically picks this up: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view

Git stream's "knowledge" reviewer setting doesn't seem to respect this file. So for us that means that one person gets suggested as the knowledge reviewer for most files because they happened to be the one to apply prettier to the whole codebase, for example.

Describe the solution you'd like
The ideal for me would be that Gitstream match GitHub's default and pick up and apply this file. I think that would be intuitive for most folks. And I think respecting this file is pretty important because it's explicitly stating places where the blame is assigning people who did something rote and don't actually have context.

Describe alternatives you've considered

  • Some easy way to opt into this with a flag. I can see why a flag is appealing vs adding default behavior, but it feels reasonable to align with the de facto standard and GH's, at least for people using gitstream with gh.
  • Manually building this out with gitstream somehow. As someone new to the tool this is pretty daunting, and I think a lot of people could benefit from baking it in as a default.
    • Maybe putting this in the pattern lib would be a good middleground.

Additional context
Thanks! This tool is very exciting to me.

@liamfd-titan liamfd-titan added the enhancement New feature or request label May 25, 2023
@vim-zz
Copy link
Collaborator

vim-zz commented May 28, 2023

Great suggestion!

@vim-zz vim-zz added the roadmap label May 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request roadmap
Projects
None yet
Development

No branches or pull requests

2 participants