Re: [RFC PATCH 0/1] Fuzzy blame
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Mar 27, 2019, 09:02 UTC
- Message-ID
- <CACsJy8D-Nwyh0tXsOiqBUnkKVm5TQcVaszdLX1FMr7vDfQ8krg@mail.gmail.com>
- In-Reply-To
- <CAJDYR9T40xaSpmL_e00WWXzxEm_j0pcTqBhvr=5mu-fTpKodmQ@mail.gmail.com>
On Wed, Mar 27, 2019 at 3:26 PM Michael Platings <michael@platin.gs> wrote:
Show 19 quoted lines
> > > Another good place to keep these revs is git-notes, > > which probably could result in faster lookups too and can be made > > visible in git-log. > > Oh wow, I really like this. A major concern I had about the revisions > file was that you don't know what a revision ID will be until it's > upstream. If you can specify *in the commit message itself* what > options should apply to git blame for that revision then that problem > is solved. And if you change your mind later, or want to ignore a > pre-existing revision then git-notes solves that problem. > > So I'm thinking you just have a commit message like this: > " > Make all function names snake_case > git-blame-ignore: fuzzy > " > And users who have blame.ignoreRevs set will have the -F/--fuzzy > option applied to that commit.
Yeah some trailer in the commit itself is also good if you know in advance it should be treated differently. I think we have git-interpret-trailers to help extract these info.
Show 6 quoted lines
> > But that's in addition to --ignoreRevsFile, not replacing it. > > I disagree. ignoreRevsFile has the major problem that the file will > need updating every time you rebase a commit to be ignored, and you'll > need to remember to edit it for cherry picks. Let's not have that > option as I think it will add unhelpful complexity.
OK I was just trying to say I did not object any current suggestions (because I didn't know much in the first place). I'll just leave this for other people to discuss :)
-- Duy