Todd Lewis <utoddl@xxxxxxxxxxxxx> writes:
> [utoddl@tarna gitbug]$ git diff master@{01-01-2012} charter.txt
> warning: Log for 'master' only goes back to Thu, 6 Jul 2017 08:19:45 -0400.
What you observed is how <ref>@{<selector>} syntax is designed to
work, and is not limited to "git diff". Any Git command e.g. "git
rev-parse master@{01-01-2012}", would and should behave the same
way.
The thing to note is that the syntax does not pay any attention to
author or committer dates recorded in the commit objects. In fact,
if you have a ref that points at an object that is not a commit-ish,
you can still use the syntax. If you did this, for example
$ git config core.logallrefupdates always
$ one=$(echo one | git hash-object --stdin -w)
$ git update-ref refs/my/blob $one
... time passes ...
$ two=$(echo two | git hash-object --stdin -w)
$ git update-ref refs/my/blob $two
then "git show my/blob@{2.minutes.ago}" will show the blob object
your refs/my/blob ref was pointing at 2 minutes ago.
And as you may know, blobs do not record any timestamp. So how does
this work?
The reason why this works is because the time in <ref>@{$time}
syntax is about asking what was pointed by the <ref> back in $time
in your repository. It does not matter what timestamp the object
that was pointed by the <ref> has (or does not have).
If you didn't create this repository back in 2012, then the syntax
"master@{01-01-2012}" that asks "Back at the beginning of 2012, what
object did the master branch point at?" does not have a sensible
answer. That can be seen in the warning you got from Git.
Hope this clarifies.
