Hi Michael,
Thanks for having taken time to respond!
You're right, ideally 36944f2b16 should have disappeared from the
output at line 5. The way the ignoring algorithm works is that it
tries to find a line in the previous commit with similar content.
Since there's so little content to compare I guess the algorithm plays
it safe and gives up.
OK, I understand.
On the one hand this is annoying because an
empty line or single curly brace should be trivial for the algorithm
to deal with. On the other hand "which change caused this empty line
to be here?" is not a very interesting question so hopefully won't be
too much of a problem for you in practice.
I agree.
There are a couple of
annoyances with the feature I'd like to fix (the main being that
there's no way to enable it globally) and I'll add this to the list.
However I'm unlikely to get to it soon. I won't complain if you beat
me to fixing it :)
Thanks for having considered the bug report.
In case it helps, I've noticed that if I add the "-w" flag (to ignore
whitespace in comparisons), the git blame output no longer shows that
revision which was asked to be ignored.
git blame -w --ignore-revs-file .git-blame-ignore-revs radius.c
I don't know whether it is a coincidence (especially when
.git-blame-ignore-revs contains in fact commits of code reformatting and
whitespace cleaning) or it would also help for other kind of commits to
ignore.
--
Julien ÉLIE
« Le bonheur, c'est de continuer à désirer ce que l'on possède. »
(Saint-Augustin)
