Thank you for your feedback! I do have some more information to provide that is confusing. I tried running `git blame -w`, and this correctly ignores the revision I tried to ignore with `--ignore-rev`, etc. So it appears that the algorithm to attribute lines to commits is capable of ignoring the commit in question (in the lines I've inspected) but it's not doing it when I use the "ignore-rev" capability—only the "ignore whitespace changes" capability. Does anyone have any ideas about why that may be the case? Does the "ignore whitespace" and "ignore commit" algorithms use different logic? I would have assumed that they shared most of the logic. I would love to provide a concrete example, but the only time I've been able to reproduce this is with proprietary code. I'll try to create a new repository with a similar commit and see if I can ignore it there. For the information of those interested, the commit I'm trying to ignore is a "reformat the world" commit. We introduced the tool "astyle" into our codebase, and as part of that effort I ran astyle over our entire codebase. Is it possible that the commit isn't being ignored because it's too big? It did change over 1300 files.... On Fri, Oct 2, 2020 at 4:44 PM Barret Rhoden <brho@xxxxxxxxxx> wrote: > > Hi - > > On 10/2/20 5:40 PM, René Scharfe wrote: > [snip] > > I don't know if these revisions are not ignored due to bugs or because > > the feature just isn't strong enough, yet, but I would expect your > > particular case to be represented by at least one of these... > > Correct. > > When skipping a revision, the algorithm attempts to find another > revision that could be responsible for the change. But it might not be > able to find anything. Consider a commit that just adds a few lines to > a file with only 'foo' and 'bar': > > commit: "Adding Lines" > ------------- > foo > +No commit > +ever touched > +these lines > bar > > If we ignored that revision, which commit do we assign those lines to? > If they were "similar" to the existing lines, then the algorithm might > match. But in general, we can't find 'correct' (as defined by a user) > matches for arbitrary changes. > > I usually run git with these settings: > > [blame] > ignorerevsfile = .git-blame-ignore-revs > markIgnoredLines = true > markUnblamableLines = true > > Which points out when --ignore-revs is doing something. > > Thanks, > > Barret > > -- -Harrison McCullough
