On Wed, Mar 27, 2019 at 3:26 PM Michael Platings <mich...@platin.gs> wrote: > > > 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. > > 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
