linux-kernel - Re: git feature request: git blame --ignore-cleanup/--ignore-trivial

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210603102303.GX31483@twin.jikos.cz>
Date:   Thu, 3 Jun 2021 12:23:03 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     git@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Jiri Kosina <trivial@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: git feature request: git blame --ignore-cleanup/--ignore-trivial

On Wed, Jun 02, 2021 at 11:20:35AM -0400, Mathieu Desnoyers wrote:
> Following a discussion with Peter Zijlstra about whether code cleanup
> and functional changes done to the Linux kernel scheduler belong to separate
> patches or should be folded together, the argument for folding cleanup
> and function changes came to be mainly motivated by the current behavior
> of git blame: code cleanup patches end up burying the important changes so
> it becomes cumbersome to find them using git blame.
> 
> 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.
> 
> Tagging patches as trivial and cleanup should be done in the patch commit message
> (possibly in the title), and enforcing proper tagging of commits is already the
> responsibility of the maintainer merging those cleanup/trivial commits into the
> Linux kernel anyway.
> 
> Under the hood, I suspect it could use something similar to git log --grep=<pattern>
> --invert-grep.
> 
> This should allow git blame users to easily filter out the noise and focus on the relevant
> functional changes.
> 
> Any maybe the patterns associated to "cleanup" and "trivial" commits should be something
> that can be configured through a git config file.

As long as the subsystem policy is consistent, eg. always split cleanups
from functional changes, and make the trivial cleanups really obvious
either from code or mentioned in the changelog, I don't see a need for
a tooling.

Going through unrelated cleanups when digging in the git history is
annoying and I think it's up to maintainers' and developers' decision
what kind of cleanups are desired (because they make the code better,
not just because they're trivial).  Mandating some sort of tagging is
just another burden, if it's not applied consistently it won't be
reliable so it won't help much.