All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: 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>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: git feature request: git blame --ignore-cleanup/--ignore-trivial
Date: Wed, 2 Jun 2021 15:37:10 -0400	[thread overview]
Message-ID: <YLfd5pWtRqde1++Y@coredump.intra.peff.net> (raw)
In-Reply-To: <30399052.5964.1622647235870.JavaMail.zimbra@efficios.com>

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

  parent reply	other threads:[~2021-06-02 19:43 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
2021-06-02 19:37 ` Jeff King [this message]
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=YLfd5pWtRqde1++Y@coredump.intra.peff.net \
    --to=peff@peff.net \
    --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.