[Bf-committers] .git-blame-ignore-revs entries.

[Ankit]

Hello
I'm getting used to it.
I'll remove several commits soon, now that I have received the
feedback on the last commit, and will use stricter conditions in the future.

My premise 
- for being lenient was that it saves other people from committing to
  the file which keeps the noise in git log low.
- for renames was that a refactoring tool was used
  with as little human intervention as possible.
- for clang-tidy being the auto-fixes feature that clang-tidy gives.

> All,

That's a new way of raising concerns on commits.

> but I really
> would still like to see smaller and clearly manual cleanups
> in git blame.

If I see "cleanup" in the title, the onus is on the committer to make
sure that it really is a cleanup. If that promise is kept, I don't see
why a cleanup commit interests you.

> Changes in this file don't even seem to go through code review.

I thought it keeps the overhead of keeping a utility file low.

Ankit


> On 29-Dec-2020, at 00:40, Ray Molenkamp via Bf-committers <bf-committers at blender.org> wrote:
> 
> All,
> 
> What's going in with this file? there's 50+ commits in there
> and I disagree with virtually every single hash I sampled
> from it.
> 
> If we want to hide large changes made by automated tools like
> the big clang-format [1] change, yeah awesome, but I really
> would still like to see smaller and clearly manual cleanups
> in git blame.
> 
> Changes in this file don't even seem to go through code review.
> In the original review [2] both Brecht and Campbell mention
> that it be "OK for larger changes" but that is not what appears to
> be happening.
> 
> This is not how this is supposed to work, is it?
> 
> --Ray
> 
> [1] https://developer.blender.org/rBe12c08e8d170b7ca40f204a5b0423c23a9fbc2c1
> [2] https://developer.blender.org/D9234
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers