Re: [RFC PATCH 0/1] Fuzzy blame

From: Michael Platings <michael@platin.gs>
Date: Mar 26, 2019, 20:26 UTC
Message-ID: <CAJDYR9RVz6ZKQ-vdC8O3LYZnGeBcGHCRtL0m6UoRrKDBsUoFOw@mail.gmail.com>
In-Reply-To: <CA+P7+xo-AHmB+Wv0Z+dpgshhmqSLEb41T-JP+NKJD8DAFARA5w@mail.gmail.com>

Show 5 quoted lines

> 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.

Hi Peff, for the use case you describe of someone stumbling across a renaming commit, your approach is clearly better. However the use case Barret & I are facing is of deliberately choosing to make a large refactoring/renaming commit, and not wanting everyone else working on the project to have to press that extra button every time they run git blame.

I think it's really important that we make this dead easy for everyone to use. The ultimate in ease of use would be for git blame to automatically pick up ignore settings without the user having to even know that it's happening. But that breaks the principle of least astonishment. The next simplest thing I can think of is to add a configuration option blame.ignoreRevs which would have the same effect, except the user has to opt in. Barret has implemented blame.ignoreRevsFile, but I think the world will be a more consistent and happier place if we dictate the location that the revisions are loaded from, in the same way as .gitignore. Deciding what that location should be is one of those bikeshed arguments which is perhaps why Barret dodged it :)

-Michael