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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 3 Jun 2021 11:33:57 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Taylor Blau <me@...ylorr.com>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        git <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 Jun 2, 2021, at 3:41 PM, Taylor Blau me@...ylorr.com wrote:

> On Wed, Jun 02, 2021 at 03:29:44PM +0000, Al Viro wrote:
>> > Any maybe the patterns associated to "cleanup" and "trivial" commits
>> > should be something that can be configured through a git config
>> > file.
>>
>> Just an observation: quite a few subtle bugs arise from mistakes in
>> what should've been a trivial cleanup.  Hell, I've seen bugs coming
>> from rebase of provably no-op patches - with commit message unchanged.
>> So IME this is counterproductive...
> 
> Yes, I find excluding revisions from 'git blame' to be rarely useful,
> exactly for this reason.
> 
> You could probably use the '--ignore-revs-file' option of 'git blame' to
> exclude commits you consider trivial ahead of time. If you had an
> 'Is-trivial' trailer, I would probably do something like:
> 
>  $ git log --format='%H %(trailers:key=Is-trivial)' |
>      grep "Is-trivial: true" | cut -d" " -f1 >exclude
>  $ git blame --ignore-revs-file exclude ...

Nice trick! So within a project which standardize on a "Cleanup: " prefix
at the beginning of the patch subject, this would look like:

git log --format='%H Subject=("%s")' file.c | grep 'Subject=(\"Cleanup: ' | cut -d" " -f1 > exclude.txt
git blame --ignore-revs-file exclude.txt file.c

I fully understand that in many cases having the entire set of revisions is
needed, because even a cleanup patch could be buggy, but IMHO it's nice to
have a way to achieve this in situations where the cleanup patches get in the
way of figuring out the most recent behavior changes in a given area of the
code.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com