Possible git blame bug?

[Domagoj Stolfa <domagoj.stolfa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]