Re: [RFC PATCH 0/1] Fuzzy blame

From: Jeff King <peff@peff.net>
To: Michael Platings <michael@platin.gs>
Cc: "Barret Rhoden" <brho@google.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org, "Stefan Beller" <stefanbeller@gmail.com>,
	"Jeff Smith" <whydoubt@gmail.com>, "René Scharfe" <l.s.r@web.de>
Subject: Re: [RFC PATCH 0/1] Fuzzy blame
Date: Mon, 25 Mar 2019 19:35:16 -0400	[thread overview]
Message-ID: <20190325233516.GB23728@sigill.intra.peff.net> (raw)
In-Reply-To: <CAJDYR9R77_+gfOgLXX_Az8iODNRyDTHAT8BAubZeptEWJViYqA@mail.gmail.com>

On Mon, Mar 25, 2019 at 11:21:19PM +0000, Michael Platings wrote:

> > I work on a project that needs a major reformatting, and one thing
> > delaying me was the lack of an ability to ignore commits during blame.
> 
> I think we understand each other well then - I'm working on a plan to
> change the variable naming rule in LLVM, and naturally other
> developers aren't keen on making git blame less useful.

This is sort of a tangent to the thread, but have you looked into tools
that provide an interactive "re-blame from the parent" operation? I use
tig for this.  Quite often my blame turns up on some boring line
(whitespace fixing, minor tweaking of a function interface, etc), and
then I want to keep digging on the "same" line, as counted by line count
(but it's OK if it's off by one or two lines, since I'm looking at a
blame of the whole file).

Obviously this isn't as automated as saying "ignore commit X, it's just
variable renaming". But it also eliminates the need to a priori figure
out all such X that affect the lines you care about. You get an answer,
your human mind says "nope, that's not interesting", and you press a
button to dig further.

I think there's room for both solutions to co-exist, but just suggesting
you to try out the one that's already been implemented if you haven't. ;)

-Peff