On Wed, Jun 02, 2021 at 11:20:35AM -0400, Mathieu Desnoyers wrote: > Considering the added value brought by splitting cleanups from functional changes > from a maintainer perspective (easier reverts) and from a reviewer perspective > (easier to focus on the functional changes), I think it would be good to improve > the git tooling to allow easily filtering out the noise from git blame. > > Perhaps a new git blame "--ignore-trivial" and/or "--ignore-cleanup" could solve > this by filtering out "trivial" and "cleanup" patches from the history it considers. There's "-w" to ignore whitespace-only changes. Since Git v2.23.0, there's also "--ignore-rev-file", which lets you ignore arbitrary commits. Since you have to generate a separate list of commits to feed it, it's a little more involved than your "--invert-grep" example. But it's also much more flexible (you can generate the file however you like, and even tweak it by hand). I do tend to agree with Al's notion that commits which are _supposed_ to be trivial sometimes end up not being so. Or another way of thinking about it is: relevance is a property of the query you're making, not the original change. So IMHO the best tool for this kind of thing is the "re-blame from parent" feature that many interactive blame viewers have (I use tig, but I'm sure other tools like magic have a similar feature). There when you land on a boring commit, it's a single key to skip past it and see how the earlier code came about. -Peff
