Hello, yesterday I came across sort of a weird behaviour with git-blame. It would appear when one queries the git blame on a specific file, such as: $ git blame <file> --since=<year> it will blame the entire file on some commit of that year, regardless of the fact whether the commit has actually touched that file or not. This seems consistent across all the tested systems: FreeBSD, macOS, Ubuntu and Fedora. An example of the blame can be seen: $ git blame tcp_output.c cd0bc69e2fdd (wollman 1995-09-22 20:05:58 +0000 29) * @(#)tcp_output.c 8.4 (Berkeley) 5/24/95 compared to: $ git blame tcp_output.c --since=2017 ^e19f2a27ed8 (Domagoj Stolfa 2017-03-12 20:43:01 +0100 29) * @(#)tcp_output.c 8.4 (Berkeley) 5/24/95 $ git blame tcp_output.c --since=2016 ^e4bdb83e76c (jceel 2016-03-13 19:50:17 +0000 29) * @(#)tcp_output.c 8.4 (Berkeley) 5/24/95 $ git blame tcp_output.c --since=2015 ^d749a6e6c70 (pfg 2015-03-13 18:42:43 +0000 29) * @(#)tcp_output.c 8.4 (Berkeley) 5/24/95 Of course, specifiying $ git blame --since=1.1.2017 gives correct results, as expected. The question is whether this is a bug or not, as --since=<year> might not be a valid filter. However, this might surprise a lot of users and mislead development. I would personally like to see this behaviour changed to either a blank report, a report of that year(making it a valid filter), but certainly not blaming it on commits that have never touched that file. -- Best regards, Domagoj Stolfa
Attachment:
signature.asc
Description: PGP signature