Re: How do I specify a revision for "git blame" by date?

From: Thomas Rast <trast@student.ethz.ch>
Date: Jun 14, 2012, 10:05 UTC
Message-ID: <877gva1a4b.fsf@thomas.inf.ethz.ch>
In-Reply-To: <4fda029d.g99uVull9jgguc/Y%perryh@pluto.rain.com>

perryh@pluto.rain.com writes:

Show 17 quoted lines

> How do I get "git blame" to operate "as of" a particular date in
> the past, without having to manually look up the corresponding
> SHA1 using "git rev-list"?  For example, I can get a report as of
> 2011-12-29 by doing something like:
>
>   $ git rev-list --all --date-order --format="%h %ai" .
>   ...
>   7c69106 2012-01-03 ...
>   b4227af 2011-12-27 ...
>   ...
>
>   $ git blame <file> b4227af
>
> but I want to have git look up the last revision prior to the given
> date, by doing something like
>
>   $ git blame <file> @{2011-12-29}

You are looking at two different dates:

a) The dates stored within the commit object:

   - committer date, similarly shown by %ci: when the commit was created.
   - author date, shown by %ai: when "this" commit was "first created".

   These are properties of the commits, and thus part of the project
   history.  Anyone who clones the project sees the same dates.

b) The dates in the reflog, tracking the movement of *your local* refs
   (like the name implies).  The HEAD reflog tracks what *you* had
   "currently checked out" at a given time.

An automated search in (b) is possible with the @{} syntax, but note that it tracks the *branch state*. It says nothing about how "current" a certain resulting commit was. For example, if you say

  git checkout v1.6.0
  sleep 2
  git checkout -
  git show '@{1 second ago}'

you will see the commit for v1.6.0 from back in 2008.

An automated search in (a) is hard, mostly because in nonlinear history there is not usually a single (and well-defined) commit that could be returned. Git could attempt to search all of your branches, like you have done above, but which one among all commits from that date should it pick? Furthermore, the result set to pick from will change if you fetch more history into your repo.

It's even worse with the author (as opposed to committer) dates: those are not even remotely close to monotonic in most repos, because they are kept across rewriting. (The committer dates would be monotonic if everyone kept their clocks in sync and avoided filter-branch tricks.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch