All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	git@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jiri Kosina <trivial@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: git feature request: git blame --ignore-cleanup/--ignore-trivial
Date: Thu, 3 Jun 2021 12:13:50 +0200	[thread overview]
Message-ID: <20210603101350.GW31483@twin.jikos.cz> (raw)
In-Reply-To: <YLej6F24Emm7SX35@zeniv-ca.linux.org.uk>

On Wed, Jun 02, 2021 at 03:29:44PM +0000, Al Viro wrote:
> On Wed, Jun 02, 2021 at 11:20:35AM -0400, Mathieu Desnoyers wrote:
> > Hi,
> > 
> > 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.
> > 
> > Thoughts ?
> 
> Just an observation: quite a few subtle bugs arise from mistakes in
> what should've been a trivial cleanup.

I was about to write such comment. Cleanups that are eg. mechanically
switching names/types/variables/... and need some manual fixup are hot
candidates for buggy patches.

  parent reply	other threads:[~2021-06-03 10:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 15:20 git feature request: git blame --ignore-cleanup/--ignore-trivial Mathieu Desnoyers
2021-06-02 15:29 ` Al Viro
2021-06-02 19:41   ` Taylor Blau
2021-06-03 15:33     ` Mathieu Desnoyers
2021-06-03 10:13   ` David Sterba [this message]
2021-06-02 19:37 ` Jeff King
2021-06-02 21:16 ` Felipe Contreras
2021-06-03 10:23 ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210603101350.GW31483@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=git@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=trivial@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.