Hello,
> >> The question is whether this is a bug or not, as --since=<year> might not be a
> >> valid filter.
> >
> > I do not think blame ever was designed to work with --since, so that
> > is indeed the case.
>
> Actually, I do see that we had a cut-off based on rev->max_age since we
> introduced it at cee7f245 ("git-pickaxe: blame rewritten.", 2006-10-19).
>
> I do not know offhand if --since=2000 _means_ --since=2000-01-01 or something
> completely different, though.
It seems to indicate something entirely different. The problem with it is that
it mentions commits that haven't even touched the file though. Output with
commit hashes that have touched that file would be sensible, albeit wrong in the
sense that the user did not want to see that behaviour.
For example, saying:
$ git blame time.h --since=2017
^e19f2a27ed8 (Domagoj Stolfa 2017-03-12 20:43:01 +0100 33) #ifndef _SYS_TIME_H_
$ git blame time.h --since=2016
^21613a57af9 (bz 2016-03-13 21:26:18 +0000 33) #ifndef _SYS_TIME_H_
$ git blame time.h --since=2015
^48507f436f0 (mav 2015-03-13 21:01:25 +0000 33) #ifndef _SYS_TIME_H_
and so on, with different hashes.
Looking at these commits:
(1) https://github.com/dstolfa/freebsd/commit/e19f2a27ed82f616d47dd4e0dc75722139e72957
(2) https://github.com/dstolfa/freebsd/commit/21613a57af9500acca9b3528958312dd3ae12bb4
(3) https://github.com/dstolfa/freebsd/commit/48507f436f07a9515c6d7108509a50dd4fd403b2
neither of them seems to touch time.h, yet git blame reports them to do so.
Interestingly enough, it seems to be taking the commit that is the closest to
the current date in that year, and blaming it on that one, regardless of what it
actually did and the file specified.
--
Best regards,
Domagoj Stolfa
Attachment:
signature.asc
Description: PGP signature